Mailing-List: contact dev-help@trafficserver.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@trafficserver.apache.org
Received-SPF: softfail (nike.apache.org: transitioning domain of
 list@toolazydogs.com does not designate 209.85.160.46 as permitted sender)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
Subject: Re: TDD/Unit testing ATS plugins
From: "Alan D. Cabrera" <list@toolazydogs.com>
In-Reply-To: <6D2D1D8D-8E6F-4DF9-AF28-2AB6DB58EA19@apache.org>
Date: Tue, 31 Dec 2013 14:44:37 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <EAB9955C-2394-4515-8A15-5345CFCE8B87@toolazydogs.com>
References: <17F6A4B1-B2D6-433D-A65A-A5029E4FFDF9@toolazydogs.com>
 <6D2D1D8D-8E6F-4DF9-AF28-2AB6DB58EA19@apache.org>
To: dev@trafficserver.apache.org


On Dec 31, 2013, at 1:53 PM, James Peach <jpeach@apache.org> wrote:

> On Dec 31, 2013, at 8:44 AM, Alan D. Cabrera <list@toolazydogs.com> =
wrote:
>=20
>> I'm looking for an example of an ATS plugin that has extensive unit =
tests.
>=20
> There are none.
>=20
>> I'm having problems linking my Boost unit tests against the plugin =
library for obvious reasons, it's a module not a shared library.
>>=20
>> I tried setting up an internal static library that the tests would =
link against but can't seem to get the object files directly included =
into the ATS plugin.
>=20
> There's no reason, in principle, that this would not work. For many =
plugins it would be reasonable to separate core functions from the =
Traffic Server bindings, and use a TDD approach for developing the core.

Yes, but Autotools is getting in the way.  I can't seem to get those =
core functions, which are in the static library that's shared by the =
plugin and tests, into the ATS plugin module.  This is the Autotools =
"example" that I'm looking for.

The dearth of specific replies tells me that everyone likely does =
integration testing only.  That, or everyone is getting ready for the =
new year's eve festivities.  ;)

> For the remainder of the tests, I'd recommend an integration testing =
approach. There is a very simple integration test harness in the ci/tsqa =
directory on master. You can use that to set up an independent ATS =
installation and drive integration tests through it.

I'll take a look at that.

> Finally, the core has the concept of "action tags", which are useful =
for testing, but not exposed through the API. Action tags would let you =
test corner cases, by setting tags to force particular APIs to fail, for =
example.

Interesting.  Where can I see examples of this form of testing?


Regards,
Alan