On Mar 8, 2014, at 5:28 PM, Alan Cabrera <l...@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 <l...@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 <chanshu...@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. >
