You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@trafficserver.apache.org by Alan Cabrera <li...@toolazydogs.com> on 2014/03/09 02:28:00 UTC

Re: TDD/Unit testing ATS plugins

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