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