[pgrouting-dev] Writing unittests for SQL functions

[Kishore Kumar]

As I see in the mailman list, the body of my previous message was
formatted in html and was skipped by mailman. So, let me remove the
html formatting and repost again. Apologies for the double post.

On Mon, May 2, 2011 at 11:58 PM, Kishore Kumar <justjkk at gmail.com> wrote:
>
> I was working with implementing CUnit tests for the core functions and after debugging a bit I commited it to a new branch(https://github.com/justjkk/pgrouting/commits/unittests). Currently it tests the boost wrapper of dijkstra and I'm hoping we can extend this to other core functions and more input scenarios as well.
> I didn't remove the python unittests because it provides testing at the sql level. I have also attached a block diagram depicting where the tests are performed. Please comment.
> Regards,
> J Kishore kumar.
> On Wed, Apr 20, 2011 at 11:14 PM, Kishore Kumar <justjkk at gmail.com> wrote:
>>
>> Hi,
>> Inline response follows:
>>
>> On Apr 20, 2011 6:24 AM, "Daniel Kastl" <daniel at georepublic.de> wrote:
>> > I had actually made a ticket for unit tests some time ago:
>> Thanks to let me know that I'm heading in the right direction.
>>
>> > Have you looked at how PostGIS is doing it? There is some chance that pgRouting and PostGIS will merge (someday), so then it would be good to have something that fits already.
>> Well, it didn't occur to me previously. I am hoping that looking at PostGIS's tests will solve most problems. I got busy with college stuff recently and hope to go through it in a couple of days.
>>
>> > One important point is in my opinion to have some suitable network graph for testing.
>> > Something that can cover all test cases and can eventually give some visual.
>> Ah, I added that simple test data and the simple test case more as a hello world of unittests and hence will replace with some large, real data soon.
>>
>> Thanks & regards,
>> J Kishore Kumar.
>>
>> > 2011/4/20 Kishore Kumar <justjkk at gmail.com>
>> >>
>> >> Hi,
>> >>
>> >> I was exploring on ways to improve the pgrouting codebase and make it suited for easier development. It struck me that writing unittests for all the pgrouting functions will help with both documentation as well as reduce the overhead of manual testing. Initially I tried using google's c++ testing framework[1] to test the c and c++ functions but encountered problems because the c functions were using postgresql library and decoupling psql interactions from the core algorithm seemed too much of a rewrite for testing.
>> >>
>> >> Hence, I resolved to implementing black box testing of individual SQL functions. Since this can be done independent of the language constraints, I explored opportunities with using python. I found python's unittest framework to be both light and flexible for the purpose. The initial attempts can be found in my python_unittests branch[2].
>> >>
>> >> The problem I'm facing is to run the tests between 'make' and 'make install' stages. Currently, the tests are run against the installed version of pgrouting found at $libdir so that testing can be done only after installing.
>> >>
>> >> Will be glad to hear any problems with the current choice of tools or if the testing approach needs to be changed.
>> >>
>> >> --
>> >> Regards,
>> >> J Kishore Kumar.
>> >>
>> >> [1] - http://code.google.com/p/googletest/
>> >> [2] - https://github.com/justjkk/pgrouting/commits/python_unittests
>> >>
>> >>
>> >> _______________________________________________
>> >> pgrouting-dev mailing list
>> >> pgrouting-dev at lists.osgeo.org
>> >> http://lists.osgeo.org/mailman/listinfo/pgrouting-dev
>> >>
>> >
>> >
>> >
>> > --
>> > Georepublic UG & Georepublic Japan
>> > eMail: daniel.kastl at georepublic.de
>> > Web: http://georepublic.de
>> >
>> > _______________________________________________
>> > pgrouting-dev mailing list
>> > pgrouting-dev at lists.osgeo.org
>> > http://lists.osgeo.org/mailman/listinfo/pgrouting-dev
>> >