Warning: in this post, we will go deeper in ‘Octopus’ garage’ – Though that might seem a bit geeky, I hope you will find interest in learning more about how Octopus is developed 
What are we going to speak about? About one tool: GreenPepper, and about how we have been using it over the last 2 months to go further in the flexibility offered by Octopus..
In the previous post, we have described how continuous integration was a wonderful process to have dynamic interactions within the Development Community, and to reach a better and quicker result, without having to make extensive ex-ante documentation…
Human interaction and feedbacks are great for ergonomics or user-experience features (or even for the transformation of a pattern from bi- to multi-currency), but you will reach a limit if you wish to tackle algorithmics: if you change a piece in the code related to calculation, imagine the time you will spend clicking on the same repayment window to simulate all the possible variations (repay a bit less than expected, a bit more, on time, before or late, with or without cents, in flat, declining or exotic loans, etc.)
Well, this limitation is actually experienced by many development teams, that involve dedicated workforces of manual testers to do the job. And the task must be so boring that you may suspect how desperate a tester must be when he finds a bug…
Well, you have understood, manually testing algorithms is long, boring, repetitive. And if you plan, like us, to release a new stable version regularly, you will just not manage it that way…
So, what do you usually do when you face a long, boring and repetitive task? You automatize it: that is a bit costly (in time) at first, but the long-term benefits are worth the investment…
Here comes GreenPepper
What is it? From a non-geek viewpoint (like mine), that looks like a wiki which is plugged directly and in real-time with the source code. It allows me to write stories with a specific syntax, that simulates actions in the software. I put also in the story what are the expected results of those actions..
Let’s take an example. Here is a story I have written a few weeks ago (click the image to view it full size)
[ Basically, I describe the story of a client, who gets a specific type of loan product, receives the money on the 01/01/06 (I check the schedule), repays correctly the first installment (I check the event and how it affects the schedule), but comes a bit early with too much money for the 2nd installment. Then, I simulate the new schedule if the MFI decides to ask only for the accrued interests, put the rest of the cash to repay part of the capital, and recalculates the schedule (and in particular, the new interests to be expected each month).]
Once the story is written, you can check if the software provides the expected results: you run the test, and you get green cells if the received amount corresponds to what was expected, red otherwise. Have a look at the picture below to see what happens when the code algorythm is partially wrong:
That’s where Andrey is entering the game. Andrey is a great programmer from Bishkek, Kyrgyzstan, who has been working in the project for more than one year now… He was eager to tackle some tricky calculations in the software, and GreenPepper was here to help him.
How did GreenPepper help Andrey (and me)?
- It allowed him to understand more easily the new rules/calculations expected: stories are much clearer than theorical and equivocal specifications…
- It allowed him to check in real time if his changes in the code had the expected impact
- As there are many other GreenPepper tests (more than 200) and that he could run them all through a batch, he was able to check whether its changes in this part of the code had no counter-effects in other unsuspected parts of the software.
In a nutshell: Using an automatized functional test tool like GreenPepper allows us to work on the algorithms securely and more efficiently. It is an excellent channel to make sure use cases are understood the same way by developers and ‘functional people’. And though Octopus is released almost once a month, we can guarrantee to our users that, from a version to another, there is no regression – that an algorythms that was working before will also work in the future.
The development team also uses another layer of tests (Unit Tests, using NUnit), but that’s too geeky for me to explain it here…
If you want to have a look at the library of GreenPepper tests of Octopus, they are freely viewable in Octopus wiki: http://wiki.octopusnetwork.org/display/OPUS/Home . You can use them to understand better the behaviour of Octopus in different situations. And if you feel that a story is missing, feel free to submit one!
