On 02/06/16 09:09, Olle E. Johansson wrote:
On 01 Jun 2016, at 08:43, Daniel-Constantin
Mierla <miconda(a)gmail.com
<mailto:miconda@gmail.com>> wrote:
Hello,
this probably needs a more elaborate discussion and planning, being
somehow related to unit testing that is planned to be approached for 5.0.
IMO, anything for testing a module should be in a subfolder inside
the module directory or inside a directory dedicated for testing. It
won't be that nice to have them at the same level with module
directories, will be a lot of noise there as a module may have more
than one unit test.
Let’s create a module_test directory that hosts various test modules
then. Naming the directory “test” makes it clear for users that it’s
not a normal production-use directory. I think creating test modules
for modules that implement API is a good thing. If we can automate
tests that’s even better. I’ll use this module as a test case and
we’ll figure it out.
If we come up with something else and need to move it, users should
not be affected, only developers. I know that we are a grumpy
group of persons that doesn’t want to change anything, but let’s hope
that we can survive us messing around with test code :-)
There is a folder
'test' now where are also the current units. Perhaps
is the best place where to create the new folder for testing modules.
Cheers,
Daniel
/O
Cheers,
Daniel
On 31/05/16 22:46, Olle E. Johansson wrote:
Hi!
In order to be able to test the API for the http_client I have created a separate module.
I couldn’t let it live in the same directory, so I created a new module directory for it.
If I keep it in the same directory the Makefile automatically links it with the
http_client so-file, which is not what I want.
I would like to store it somewhere - I can either commit is a module that doesn’t compile
by default, store it in a hidden branch and forget about it or get help in fixing the
Makefile so it can optionally compile in the same directory.
Which would be the way forward?
Right now it doesn’t do much more than bind to the API, but hopefully it will soon be
able to test all the provided API functions.
/O
_______________________________________________
sr-dev mailing list
sr-dev(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
--
Daniel-Constantin Mierla
http://www.asipto.com -
http://www.kamailio.org
http://twitter.com/#!/miconda -
http://www.linkedin.com/in/miconda
_______________________________________________
sr-dev mailing list
sr-dev(a)lists.sip-router.org <mailto:sr-dev@lists.sip-router.org>
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev