You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@trafficserver.apache.org by James Peach <jp...@apache.org> on 2014/01/02 18:04:42 UTC

Re: TDD/Unit testing ATS plugins

On Dec 31, 2013, at 2:44 PM, Alan D. Cabrera <li...@toolazydogs.com> wrote:

> 
> On Dec 31, 2013, at 1:53 PM, James Peach <jp...@apache.org> wrote:
> 
>> On Dec 31, 2013, at 8:44 AM, Alan D. Cabrera <li...@toolazydogs.com> wrote:
>> 
>>> I'm looking for an example of an ATS plugin that has extensive unit tests.
>> 
>> There are none.
>> 
>>> I'm having problems linking my Boost unit tests against the plugin library for obvious reasons, it's a module not a shared library.
>>> 
>>> 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.
>> 
>> 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.

You should be able to build the core as an autotools convenience library, then link that into the test harness and the plugin.

> 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?

It's not really used in testing right now, but that's an obvious application. If you search for "is_action_tag_set()" in the source, you can see a number of examples.

J



Re: TDD/Unit testing ATS plugins

Posted by Leif Hedstrom <zw...@apache.org>.

> On Feb 24, 2014, at 8:51 PM, Alan Cabrera <li...@toolazydogs.com> wrote:
> 
> I wanted to start goofing around with this in a public place so people can comment/participate.  Would it make sense to do this on github and if it ever gels into something useful I could submit a patch?

Yep, just fork the official ATS repo on GitHub, and when done you can make a pull request there. 

Cheers,

-- Leif 
> 
> 
> Regards,
> Alan
> 
>> On Jan 10, 2014, at 11:41 AM, Alan Cabrera <li...@toolazydogs.com> wrote:
>> 
>> +1 a good mocked library would be awesome.  
>> 
>> Do more experienced ATS developers know of any blockers to us writing a mock library for testing?
>> 
>> 
>> Regards,
>> Alan
>> 
>>> On Jan 10, 2014, at 11:08 AM, Shu Kit Chan <ch...@gmail.com> wrote:
>>> 
>>> That's just unit tests for utilities and helper classes for the plugin.
>>> I also want a stub library, too, for writing unit tests for plugin.
>>> 
>>> 
>>>> On Fri, Jan 10, 2014 at 10:59 AM, James Peach <jp...@apache.org> wrote:
>>>> 
>>>>> On Jan 3, 2014, at 8:48 AM, Alan D. Cabrera <li...@toolazydogs.com> wrote:
>>>>> 
>>>>> 
>>>>>> On Jan 2, 2014, at 9:04 AM, James Peach <jp...@apache.org> wrote:
>>>>>> 
>>>>>> On Dec 31, 2013, at 2:44 PM, Alan D. Cabrera <li...@toolazydogs.com>
>>>> wrote:
>>>>>> 
>>>>>>> 
>>>>>>>> On Dec 31, 2013, at 1:53 PM, James Peach <jp...@apache.org> wrote:
>>>>>>>> 
>>>>>>>> On Dec 31, 2013, at 8:44 AM, Alan D. Cabrera <li...@toolazydogs.com>
>>>> wrote:
>>>>>>>> 
>>>>>>>>> I'm looking for an example of an ATS plugin that has extensive unit
>>>> tests.
>>>>>>>> 
>>>>>>>> There are none.
>>>>>>>> 
>>>>>>>>> I'm having problems linking my Boost unit tests against the plugin
>>>> library for obvious reasons, it's a module not a shared library.
>>>>>>>>> 
>>>>>>>>> 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.
>>>>>>>> 
>>>>>>>> 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.
>>>>>> 
>>>>>> You should be able to build the core as an autotools convenience
>>>> library, then link that into the test harness and the plugin.
>>>>> 
>>>>> Yes, I agree but getting that autotools convenience library to be
>>>> included in the plugin module is what is causing problems for me.  I
>>>> reference the convenience library in my plugin module but the object files
>>>> do not get included within.  I could make it into a shared library but that
>>>> would make things messier, imo.
>>>> 
>>>> I just remembered that the ESI plugin does this ....
>>>> 
>>>> 
>>>> https://github.com/apache/trafficserver/blob/master/plugins/experimental/esi/Makefile.am
>>>> 
>>>> J
> 

Re: TDD/Unit testing ATS plugins

Posted by Alan Cabrera <li...@toolazydogs.com>.
Thanks!  I’m going to start tinkering around in 

https://github.com/maguro/trafficserver

Feel free to watch or, even better, help!


Regards,
Alan

On Feb 25, 2014, at 3:07 PM, James Peach <jp...@apache.org> wrote:

> On Feb 24, 2014, at 7:51 PM, Alan Cabrera <li...@toolazydogs.com> wrote:
> 
>> I wanted to start goofing around with this in a public place so people can comment/participate.  Would it make sense to do this on github and if it ever gels into something useful I could submit a patch?
> 
> Take a look at ci/tsqa. I started a little integration test harness there. We also now have the --enable-example-plugins build option which installed the example plugins for testing purposes ...
> 
>> 
>> 
>> Regards,
>> Alan
>> 
>> On Jan 10, 2014, at 11:41 AM, Alan Cabrera <li...@toolazydogs.com> wrote:
>> 
>>> +1 a good mocked library would be awesome.  
>>> 
>>> Do more experienced ATS developers know of any blockers to us writing a mock library for testing?
>>> 
>>> 
>>> Regards,
>>> Alan
>>> 
>>> On Jan 10, 2014, at 11:08 AM, Shu Kit Chan <ch...@gmail.com> wrote:
>>> 
>>>> That's just unit tests for utilities and helper classes for the plugin.
>>>> I also want a stub library, too, for writing unit tests for plugin.
>>>> 
>>>> 
>>>> On Fri, Jan 10, 2014 at 10:59 AM, James Peach <jp...@apache.org> wrote:
>>>> 
>>>>> On Jan 3, 2014, at 8:48 AM, Alan D. Cabrera <li...@toolazydogs.com> wrote:
>>>>> 
>>>>>> 
>>>>>> On Jan 2, 2014, at 9:04 AM, James Peach <jp...@apache.org> wrote:
>>>>>> 
>>>>>>> On Dec 31, 2013, at 2:44 PM, Alan D. Cabrera <li...@toolazydogs.com>
>>>>> wrote:
>>>>>>> 
>>>>>>>> 
>>>>>>>> On Dec 31, 2013, at 1:53 PM, James Peach <jp...@apache.org> wrote:
>>>>>>>> 
>>>>>>>>> On Dec 31, 2013, at 8:44 AM, Alan D. Cabrera <li...@toolazydogs.com>
>>>>> wrote:
>>>>>>>>> 
>>>>>>>>>> I'm looking for an example of an ATS plugin that has extensive unit
>>>>> tests.
>>>>>>>>> 
>>>>>>>>> There are none.
>>>>>>>>> 
>>>>>>>>>> I'm having problems linking my Boost unit tests against the plugin
>>>>> library for obvious reasons, it's a module not a shared library.
>>>>>>>>>> 
>>>>>>>>>> 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.
>>>>>>>>> 
>>>>>>>>> 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.
>>>>>>> 
>>>>>>> You should be able to build the core as an autotools convenience
>>>>> library, then link that into the test harness and the plugin.
>>>>>> 
>>>>>> Yes, I agree but getting that autotools convenience library to be
>>>>> included in the plugin module is what is causing problems for me.  I
>>>>> reference the convenience library in my plugin module but the object files
>>>>> do not get included within.  I could make it into a shared library but that
>>>>> would make things messier, imo.
>>>>> 
>>>>> I just remembered that the ESI plugin does this ....
>>>>> 
>>>>> 
>>>>> https://github.com/apache/trafficserver/blob/master/plugins/experimental/esi/Makefile.am
>>>>> 
>>>>> J
>>>>> 
>>> 
>> 
> 


Re: TDD/Unit testing ATS plugins

Posted by James Peach <jp...@apache.org>.
On Feb 24, 2014, at 7:51 PM, Alan Cabrera <li...@toolazydogs.com> wrote:

> I wanted to start goofing around with this in a public place so people can comment/participate.  Would it make sense to do this on github and if it ever gels into something useful I could submit a patch?

Take a look at ci/tsqa. I started a little integration test harness there. We also now have the --enable-example-plugins build option which installed the example plugins for testing purposes ...

> 
> 
> Regards,
> Alan
> 
> On Jan 10, 2014, at 11:41 AM, Alan Cabrera <li...@toolazydogs.com> wrote:
> 
>> +1 a good mocked library would be awesome.  
>> 
>> Do more experienced ATS developers know of any blockers to us writing a mock library for testing?
>> 
>> 
>> Regards,
>> Alan
>> 
>> On Jan 10, 2014, at 11:08 AM, Shu Kit Chan <ch...@gmail.com> wrote:
>> 
>>> That's just unit tests for utilities and helper classes for the plugin.
>>> I also want a stub library, too, for writing unit tests for plugin.
>>> 
>>> 
>>> On Fri, Jan 10, 2014 at 10:59 AM, James Peach <jp...@apache.org> wrote:
>>> 
>>>> On Jan 3, 2014, at 8:48 AM, Alan D. Cabrera <li...@toolazydogs.com> wrote:
>>>> 
>>>>> 
>>>>> On Jan 2, 2014, at 9:04 AM, James Peach <jp...@apache.org> wrote:
>>>>> 
>>>>>> On Dec 31, 2013, at 2:44 PM, Alan D. Cabrera <li...@toolazydogs.com>
>>>> wrote:
>>>>>> 
>>>>>>> 
>>>>>>> On Dec 31, 2013, at 1:53 PM, James Peach <jp...@apache.org> wrote:
>>>>>>> 
>>>>>>>> On Dec 31, 2013, at 8:44 AM, Alan D. Cabrera <li...@toolazydogs.com>
>>>> wrote:
>>>>>>>> 
>>>>>>>>> I'm looking for an example of an ATS plugin that has extensive unit
>>>> tests.
>>>>>>>> 
>>>>>>>> There are none.
>>>>>>>> 
>>>>>>>>> I'm having problems linking my Boost unit tests against the plugin
>>>> library for obvious reasons, it's a module not a shared library.
>>>>>>>>> 
>>>>>>>>> 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.
>>>>>>>> 
>>>>>>>> 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.
>>>>>> 
>>>>>> You should be able to build the core as an autotools convenience
>>>> library, then link that into the test harness and the plugin.
>>>>> 
>>>>> Yes, I agree but getting that autotools convenience library to be
>>>> included in the plugin module is what is causing problems for me.  I
>>>> reference the convenience library in my plugin module but the object files
>>>> do not get included within.  I could make it into a shared library but that
>>>> would make things messier, imo.
>>>> 
>>>> I just remembered that the ESI plugin does this ....
>>>> 
>>>> 
>>>> https://github.com/apache/trafficserver/blob/master/plugins/experimental/esi/Makefile.am
>>>> 
>>>> J
>>>> 
>> 
> 


Re: TDD/Unit testing ATS plugins

Posted by Alan Cabrera <li...@toolazydogs.com>.
I wanted to start goofing around with this in a public place so people can comment/participate.  Would it make sense to do this on github and if it ever gels into something useful I could submit a patch?


Regards,
Alan

On Jan 10, 2014, at 11:41 AM, Alan Cabrera <li...@toolazydogs.com> wrote:

> +1 a good mocked library would be awesome.  
> 
> Do more experienced ATS developers know of any blockers to us writing a mock library for testing?
> 
> 
> Regards,
> Alan
> 
> On Jan 10, 2014, at 11:08 AM, Shu Kit Chan <ch...@gmail.com> wrote:
> 
>> That's just unit tests for utilities and helper classes for the plugin.
>> I also want a stub library, too, for writing unit tests for plugin.
>> 
>> 
>> On Fri, Jan 10, 2014 at 10:59 AM, James Peach <jp...@apache.org> wrote:
>> 
>>> On Jan 3, 2014, at 8:48 AM, Alan D. Cabrera <li...@toolazydogs.com> wrote:
>>> 
>>>> 
>>>> On Jan 2, 2014, at 9:04 AM, James Peach <jp...@apache.org> wrote:
>>>> 
>>>>> On Dec 31, 2013, at 2:44 PM, Alan D. Cabrera <li...@toolazydogs.com>
>>> wrote:
>>>>> 
>>>>>> 
>>>>>> On Dec 31, 2013, at 1:53 PM, James Peach <jp...@apache.org> wrote:
>>>>>> 
>>>>>>> On Dec 31, 2013, at 8:44 AM, Alan D. Cabrera <li...@toolazydogs.com>
>>> wrote:
>>>>>>> 
>>>>>>>> I'm looking for an example of an ATS plugin that has extensive unit
>>> tests.
>>>>>>> 
>>>>>>> There are none.
>>>>>>> 
>>>>>>>> I'm having problems linking my Boost unit tests against the plugin
>>> library for obvious reasons, it's a module not a shared library.
>>>>>>>> 
>>>>>>>> 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.
>>>>>>> 
>>>>>>> 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.
>>>>> 
>>>>> You should be able to build the core as an autotools convenience
>>> library, then link that into the test harness and the plugin.
>>>> 
>>>> Yes, I agree but getting that autotools convenience library to be
>>> included in the plugin module is what is causing problems for me.  I
>>> reference the convenience library in my plugin module but the object files
>>> do not get included within.  I could make it into a shared library but that
>>> would make things messier, imo.
>>> 
>>> I just remembered that the ESI plugin does this ....
>>> 
>>> 
>>> https://github.com/apache/trafficserver/blob/master/plugins/experimental/esi/Makefile.am
>>> 
>>> J
>>> 
> 


Re: TDD/Unit testing ATS plugins

Posted by James Peach <jp...@apache.org>.
On Mar 8, 2014, at 5:28 PM, Alan Cabrera <li...@toolazydogs.com> wrote:

> So, I took a crack at this and it seems that InkAPI.cc has a mix of API and utility code; utility code being calls such as TSUrlSchemeGet().  
> 
> To me it seems to only make sense to mock API calls such as TSPluginRegister() and _TSmalloc().  But how will mocked tests execute code that uses both the mocked API and utility code?

Could you give me an example of which API you would like to mock, and what behaviour you would like?

> 
> 
> One way that can happen is if the proxy code is split out into API code and “utility” code with the latter being pushed out into a shared library.  This “utility” library would be shared between the ATS server and mock library. 
> 
> I guess another way could be to break out the “utility” code in a separate file say InkAPIUtilities.cc and that file could be also included in the mock library as well as the ATS server.
> 
> Thoughts?
> 
> 
> Regards,
> Alan
> 
> 
> On Jan 10, 2014, at 11:41 AM, Alan Cabrera <li...@toolazydogs.com> wrote:
> 
>> +1 a good mocked library would be awesome.  
>> 
>> Do more experienced ATS developers know of any blockers to us writing a mock library for testing?
>> 
>> 
>> Regards,
>> Alan
>> 
>> On Jan 10, 2014, at 11:08 AM, Shu Kit Chan <ch...@gmail.com> wrote:
>> 
>>> That's just unit tests for utilities and helper classes for the plugin.
>>> I also want a stub library, too, for writing unit tests for plugin.
> 


Re: TDD/Unit testing ATS plugins

Posted by Alan Cabrera <li...@toolazydogs.com>.
So, I took a crack at this and it seems that InkAPI.cc has a mix of API and utility code; utility code being calls such as TSUrlSchemeGet().  

To me it seems to only make sense to mock API calls such as TSPluginRegister() and _TSmalloc().  But how will mocked tests execute code that uses both the mocked API and utility code?  

One way that can happen is if the proxy code is split out into API code and “utility” code with the latter being pushed out into a shared library.  This “utility” library would be shared between the ATS server and mock library. 

I guess another way could be to break out the “utility” code in a separate file say InkAPIUtilities.cc and that file could be also included in the mock library as well as the ATS server.

Thoughts?


Regards,
Alan


On Jan 10, 2014, at 11:41 AM, Alan Cabrera <li...@toolazydogs.com> wrote:

> +1 a good mocked library would be awesome.  
> 
> Do more experienced ATS developers know of any blockers to us writing a mock library for testing?
> 
> 
> Regards,
> Alan
> 
> On Jan 10, 2014, at 11:08 AM, Shu Kit Chan <ch...@gmail.com> wrote:
> 
>> That's just unit tests for utilities and helper classes for the plugin.
>> I also want a stub library, too, for writing unit tests for plugin.


Re: TDD/Unit testing ATS plugins

Posted by Alan Cabrera <li...@toolazydogs.com>.
+1 a good mocked library would be awesome.  

Do more experienced ATS developers know of any blockers to us writing a mock library for testing?


Regards,
Alan

On Jan 10, 2014, at 11:08 AM, Shu Kit Chan <ch...@gmail.com> wrote:

> That's just unit tests for utilities and helper classes for the plugin.
> I also want a stub library, too, for writing unit tests for plugin.
> 
> 
> On Fri, Jan 10, 2014 at 10:59 AM, James Peach <jp...@apache.org> wrote:
> 
>> On Jan 3, 2014, at 8:48 AM, Alan D. Cabrera <li...@toolazydogs.com> wrote:
>> 
>>> 
>>> On Jan 2, 2014, at 9:04 AM, James Peach <jp...@apache.org> wrote:
>>> 
>>>> On Dec 31, 2013, at 2:44 PM, Alan D. Cabrera <li...@toolazydogs.com>
>> wrote:
>>>> 
>>>>> 
>>>>> On Dec 31, 2013, at 1:53 PM, James Peach <jp...@apache.org> wrote:
>>>>> 
>>>>>> On Dec 31, 2013, at 8:44 AM, Alan D. Cabrera <li...@toolazydogs.com>
>> wrote:
>>>>>> 
>>>>>>> I'm looking for an example of an ATS plugin that has extensive unit
>> tests.
>>>>>> 
>>>>>> There are none.
>>>>>> 
>>>>>>> I'm having problems linking my Boost unit tests against the plugin
>> library for obvious reasons, it's a module not a shared library.
>>>>>>> 
>>>>>>> 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.
>>>>>> 
>>>>>> 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.
>>>> 
>>>> You should be able to build the core as an autotools convenience
>> library, then link that into the test harness and the plugin.
>>> 
>>> Yes, I agree but getting that autotools convenience library to be
>> included in the plugin module is what is causing problems for me.  I
>> reference the convenience library in my plugin module but the object files
>> do not get included within.  I could make it into a shared library but that
>> would make things messier, imo.
>> 
>> I just remembered that the ESI plugin does this ....
>> 
>> 
>> https://github.com/apache/trafficserver/blob/master/plugins/experimental/esi/Makefile.am
>> 
>> J
>> 


Re: TDD/Unit testing ATS plugins

Posted by Shu Kit Chan <ch...@gmail.com>.
That's just unit tests for utilities and helper classes for the plugin.
I also want a stub library, too, for writing unit tests for plugin.


On Fri, Jan 10, 2014 at 10:59 AM, James Peach <jp...@apache.org> wrote:

> On Jan 3, 2014, at 8:48 AM, Alan D. Cabrera <li...@toolazydogs.com> wrote:
>
> >
> > On Jan 2, 2014, at 9:04 AM, James Peach <jp...@apache.org> wrote:
> >
> >> On Dec 31, 2013, at 2:44 PM, Alan D. Cabrera <li...@toolazydogs.com>
> wrote:
> >>
> >>>
> >>> On Dec 31, 2013, at 1:53 PM, James Peach <jp...@apache.org> wrote:
> >>>
> >>>> On Dec 31, 2013, at 8:44 AM, Alan D. Cabrera <li...@toolazydogs.com>
> wrote:
> >>>>
> >>>>> I'm looking for an example of an ATS plugin that has extensive unit
> tests.
> >>>>
> >>>> There are none.
> >>>>
> >>>>> I'm having problems linking my Boost unit tests against the plugin
> library for obvious reasons, it's a module not a shared library.
> >>>>>
> >>>>> 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.
> >>>>
> >>>> 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.
> >>
> >> You should be able to build the core as an autotools convenience
> library, then link that into the test harness and the plugin.
> >
> > Yes, I agree but getting that autotools convenience library to be
> included in the plugin module is what is causing problems for me.  I
> reference the convenience library in my plugin module but the object files
> do not get included within.  I could make it into a shared library but that
> would make things messier, imo.
>
> I just remembered that the ESI plugin does this ....
>
>
> https://github.com/apache/trafficserver/blob/master/plugins/experimental/esi/Makefile.am
>
> J
>

Re: TDD/Unit testing ATS plugins

Posted by James Peach <jp...@apache.org>.
On Jan 3, 2014, at 8:48 AM, Alan D. Cabrera <li...@toolazydogs.com> wrote:

> 
> On Jan 2, 2014, at 9:04 AM, James Peach <jp...@apache.org> wrote:
> 
>> On Dec 31, 2013, at 2:44 PM, Alan D. Cabrera <li...@toolazydogs.com> wrote:
>> 
>>> 
>>> On Dec 31, 2013, at 1:53 PM, James Peach <jp...@apache.org> wrote:
>>> 
>>>> On Dec 31, 2013, at 8:44 AM, Alan D. Cabrera <li...@toolazydogs.com> wrote:
>>>> 
>>>>> I'm looking for an example of an ATS plugin that has extensive unit tests.
>>>> 
>>>> There are none.
>>>> 
>>>>> I'm having problems linking my Boost unit tests against the plugin library for obvious reasons, it's a module not a shared library.
>>>>> 
>>>>> 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.
>>>> 
>>>> 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.
>> 
>> You should be able to build the core as an autotools convenience library, then link that into the test harness and the plugin.
> 
> Yes, I agree but getting that autotools convenience library to be included in the plugin module is what is causing problems for me.  I reference the convenience library in my plugin module but the object files do not get included within.  I could make it into a shared library but that would make things messier, imo.

I just remembered that the ESI plugin does this ....

https://github.com/apache/trafficserver/blob/master/plugins/experimental/esi/Makefile.am

J

Re: TDD/Unit testing ATS plugins

Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
On Jan 2, 2014, at 9:04 AM, James Peach <jp...@apache.org> wrote:

> On Dec 31, 2013, at 2:44 PM, Alan D. Cabrera <li...@toolazydogs.com> wrote:
> 
>> 
>> On Dec 31, 2013, at 1:53 PM, James Peach <jp...@apache.org> wrote:
>> 
>>> On Dec 31, 2013, at 8:44 AM, Alan D. Cabrera <li...@toolazydogs.com> wrote:
>>> 
>>>> I'm looking for an example of an ATS plugin that has extensive unit tests.
>>> 
>>> There are none.
>>> 
>>>> I'm having problems linking my Boost unit tests against the plugin library for obvious reasons, it's a module not a shared library.
>>>> 
>>>> 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.
>>> 
>>> 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.
> 
> You should be able to build the core as an autotools convenience library, then link that into the test harness and the plugin.

Yes, I agree but getting that autotools convenience library to be included in the plugin module is what is causing problems for me.  I reference the convenience library in my plugin module but the object files do not get included within.  I could make it into a shared library but that would make things messier, imo.


Regards,
Alan