EUnit Testing gen_fsm – Part 3

This third part will add the deal closure API as well as refactoring the code, we will also see the inception of the Automated Test Generating machinery.

Sixth Iteration – Deal closing API and the beginning of the ATG machinery

Buyer and Seller can now insert their items, and wish to close the deal, for this we need some kind of “security”. To implement this, the buyer and seller must both agree on the item and the cash. They both query the tradepost for it’s contents, get the item name and the cash amount, then if they agree, they can send an okay to the tradepost with the same item name and the same cash and their Pid. If the tradepost contains an item with that name, and that cash, the tradepost sends the item to the buyer and the cash to the seller. The tradepost then terminates.

For this parallelised receive, the syntax of the symbolic language is extended with

To pull this off, we need to extend the state with a holder for the agreed parts Pids, this will reveal a flaw with the current syntax that has not been so evident until now (bu surely nagging) that will need to be countered.

Greatness, but, in order for this to work, some modification had to be done to all previous tests! We had to extend the state-record with new fields, and the result is that the loopdata assertion had to be changed in each test! What if we had 1000 previous tests? *pulls hair in desperation*. Also, after this success, I made some refactoring, something that _should_ be done after each tests + code + success. This is also a great thing, once you have a nice big set of tests, refactoring can always be tested to preserve the logic by running your tests *thumbs up*.

With this success, it’s time to hunt the real cornercase-bugs using Automated Test Generation, a very strong piece of machinery, that requieres some setup. Oh, and just in case, if you forgot how it all fits together…

Automated Test Generation – inception

As we wish to generate complex (almost the same as long) test sequences, and do not wish to enter them by hand, we want to have a piece of machinery which makes this for us. An immediate question that comes to mind is then, how does the machinery know which sequences are actually valid? Well, that is for us to know and express. Here we can draw inspiration from from Hoare Logic and use that notion for our automated test generator. A good candidate for this would be a syntax similar to something as

We would thus want the machinery to behave as follows. Given a current gen_fsm state, and the list of all rules, return a list of all rules for which the PreCondPred holds. From this list of rules, choose one randomly, and apply execute Program. After execution, check if PostCondPred holds true. If not, record failure. On Success, repeat process with random selection of valid rule and application, etc.

For this to work, we need to write our own generator, for this, we can peek at the EUnit User’s Guide section on Lazy Generators. However, this should be discussed in the next part of this series. For this purpose, the iterations have ended.

Ps: I apologize for the long delay before this post came, but I had a lot to do at the sidelines.