I still think catch will work better.. it is lighter and easier to make tests
for no binaries needed
On Thursday, May 25, 2017 02:23:02 PM CDT, Leif Hedstrom
wrote:
> On May 24, 2017, at 10:17 PM, James Peach wrote:
>
>
>
> On 24 May 2017, at 15:00, Alan Carroll wrote:
Add it to our tree or automate a clone. We will need to have the Makefiles
build and test it.
-Bryan
> On May 25, 2017, at 12:22 PM, Leif Hedstrom wrote:
>
>
>> On May 24, 2017, at 10:17 PM, James Peach wrote:
>>
>>
>>
>> On 24 May 2017, at 15:00, Alan Carroll wrote:
>>
>>> James; it's
> On May 24, 2017, at 10:17 PM, James Peach wrote:
>
>
>
> On 24 May 2017, at 15:00, Alan Carroll wrote:
>
>> James; it's precisely because those tests don't depend on anything else in
>> traffic_server that it seems bogus to require building and running it to do
>> the tests. If you're in
I am not against this.
I would only point out that from experience in the past I found many C++
developers like the catch library better. https://github.com/philsquared/Catch
Jason
On Wednesday, May 24, 2017 04:38:13 PM CDT, Bryan Call
wrote:I am in favor of using GTest fo
>>The tests drag in traffic_server because of the link-time dependencies
>>of the systems they are testing, not because of the test framework.
This is exactly right. I would go on by saying how I want to clean this mess
upThe main point we have to understand is that the current build logic
On 24 May 2017, at 15:00, Alan Carroll wrote:
James; it's precisely because those tests don't depend on anything
else in traffic_server that it seems bogus to require building and
running it to do the tests. If you're in a tight edit/compile/test
cycle it's nice to not have to drag in everyt
James; it's precisely because those tests don't depend on anything else in
traffic_server that it seems bogus to require building and running it to do the
tests. If you're in a tight edit/compile/test cycle it's nice to not have to
drag in everything else.
On Wednesday, May 24, 2017, 4:38:08 P
I am in favor of using GTest for unit testing. There is a lot of documentation
and support for it. I would rely on the OS's GTest install and test for it in
autoconf.
autest should be used for integration testing and tsqa will be removed, so
people don’t accidentally write tests for it.
-Bry
> On May 24, 2017, at 11:28 AM, Alan Carroll
> wrote:
>
> Even though I wrote TestBox I think we need to migrate away from it. It's big
> flaw is it is built to support regression tests which means using it involves
> bringing up the traffic_server process. That's much more heavy weight than
Even though I wrote TestBox I think we need to migrate away from it. It's big
flaw is it is built to support regression tests which means using it involves
bringing up the traffic_server process. That's much more heavy weight than a
good unit test framework should be. Real unit testing should lo
> Do we want to stick with the “make check/TestBox”?
> Based on what I have seen so far on this thread looks like people
generally like GTest. Any more ideas or suggestions? Do we drop the GTest
idea?
I wrote some simple unit tests for HTTP/2 related stuff with TestBox and
actually I have some for
One framework and justice for all (or to rule them all) :)
> One framework :)
I think most of us already agree that we should have: 1 unit test framework and
1 integration test framework and have all the tests run as part of our build /
verification stage.
How to get to that point is where I t
I would suggest for unit testing.
https://github.com/philsquared/Catch
This has been nice to use. This does not require use to sync a bunch of
binaries to get it to work.
I think most the of the plugins will test better with AuTest. There will still
be a need to unit test APIs in trafficserver or
For full up plugin testing we (Yahoo!) are using the AUTest framework. In fact
there are already plugin based tests checked in to master (see
tests/gold_tests/pluginTests/header_rewrite for an example). I think that is
fine for testing the plugin in situ and we should adopt it as our preferred
On 20 May 2017, at 20:12, gan...@apache.org wrote:
Hi trafficserver-dev,
(1) I was wondering if we have any preference for a C/C++ unit test
framework in the ATS community.
Background and thoughts:
I needed a unit test framework quickly to do TDD in order to deliver
the AWS auth v4 (PR #1
(1) I used gtest for an other project before, and it was pretty nice.
Although I'm not so familiar with test frameworks, I think it's a good
choice. At least, perspective of features. If I have to bring up one sad
thing, it isn't provided with any packaging system (e.g. rpm, brew), afaik.
So, initi
For 1), We have a long standing PR to add a unit test framework for
C++ plugins. We also wrote tests for the webp transform plugin using
that framework. We can revisit this and see if this is a good starting
point.
https://github.com/apache/trafficserver/pull/408
We still need a good unit test fra
17 matches
Mail list logo
