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
at 6:09 PM, Gancho Tenev wrote:
>
> 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 o
>>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
people don’t accidentally write tests for it.
-Bryan
> On May 23, 2017, at 6:09 PM, Gancho Tenev wrote:
>
> 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
or it.
-Bryan
> On May 23, 2017, at 6:09 PM, Gancho Tenev wrote:
>
> 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 h
much more heavy weight than a
> good unit test framework should be. Real unit testing should load as little
> additional code as possible.
There are a number of examples of using TestBox and REGRESSION_TEST for unit
tests that don't depend on traffic_server. Depending on wha
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 test
Thanks,
Masakazu
On Tue, May 23, 2017 at 6:09 PM, Gancho Tenev wrote:
> 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 al
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 wher
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
d.
Thanks,
Masakazu
On Sat, May 20, 2017 at 8:12 PM, 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
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
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 #1946).
Google Test seemed easy to bootstrap, popular
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 #1946).
Google Test seemed easy to bootstrap, popular
19 matches
Mail list logo
