so the trick is to use findall? and the problem is that nobody knows prolog?
why not then just implement findall for other languages? it's like 2 or 3 loops anyway, if you don't care about performance. which you don't since this generates test data
Findall is just a cartesian product...something easily available in pretty much any language out there. Not that I think Prolog is a bad fit for test data generation, just that this example is entirely too simple to show its power.
Where Prolog becomes really powerful for this use case is modeling the underlying business rules and selectively creating test cases that acknowledge those rules. A tiny bit of familiarity with Prolog goes a long way here. I've modeled about 95% of the underlying logic of 50k SLOC Java business rule systems using less than a hundred lines of Prolog. And the ability to infer both forward and backwards is extremely powerful (ex. if you have created F(X,Y) = Z, then you implicitly have a rule for determining X given Y and Z).
Yes, this example is simple. IMO it's best to introduce people to what they are familiar with. I didn't want to write an example that demonstrated the full power of prolog but lost 90% of the crowd. My hope was that this would spark curiosity in how prolog can be used to generate test cases.
At the moment I'm using the technique in the post to generate happy path test cases for an application with lots of buisness rules.
RUGE [1] is another open source PROLOG framework for functional and load testing. Brendon McCarthy originally developed it for testing financial applications at American Express.
Brendon presented it at the 2013 Workshop on Domain-Specific Languages for Financial Systems [2]. One observation made by the Haskellers was that PROLOG approaches such as these are attempting to solve a problem that has already been solved by QuickCheck [3].
Ruge looks interesting but the last commit is November 2013. Is the project still active?
Ruge is dependent on SICStus Prolog[1] which is proprietary. Has anyone had success running ruge on an opensource prolog such as GNU Prolog, swi-prolog, or yap?
5 comments
[ 6.1 ms ] story [ 24.0 ms ] threadwhy not then just implement findall for other languages? it's like 2 or 3 loops anyway, if you don't care about performance. which you don't since this generates test data
Where Prolog becomes really powerful for this use case is modeling the underlying business rules and selectively creating test cases that acknowledge those rules. A tiny bit of familiarity with Prolog goes a long way here. I've modeled about 95% of the underlying logic of 50k SLOC Java business rule systems using less than a hundred lines of Prolog. And the ability to infer both forward and backwards is extremely powerful (ex. if you have created F(X,Y) = Z, then you implicitly have a rule for determining X given Y and Z).
Yes, this example is simple. IMO it's best to introduce people to what they are familiar with. I didn't want to write an example that demonstrated the full power of prolog but lost 90% of the crowd. My hope was that this would spark curiosity in how prolog can be used to generate test cases.
At the moment I'm using the technique in the post to generate happy path test cases for an application with lots of buisness rules.
Brendon presented it at the 2013 Workshop on Domain-Specific Languages for Financial Systems [2]. One observation made by the Haskellers was that PROLOG approaches such as these are attempting to solve a problem that has already been solved by QuickCheck [3].
[1] http://bmccarthy.bitbucket.org/ruge/faq.html [2] http://dslfin.org/ [3] https://en.wikipedia.org/wiki/QuickCheck
Ruge is dependent on SICStus Prolog[1] which is proprietary. Has anyone had success running ruge on an opensource prolog such as GNU Prolog, swi-prolog, or yap?
[1] http://bmccarthy.bitbucket.org/ruge/download.html