On the evening of last April 24th at the Ugly Duckling office in Amsterdam we celebrated the birth of our new series of events for financial engineers. We called it Financial Engineering Netherlands, and we hope we will create a community of specialists that everybody can join and consult.

The aims of Financial Engineering Netherlands are

• to bring together experts with similar passions, who are willing to improve themselves by sharing their knowledge with others, keeping the topics within the interest range of financial engineers, and hence including testing, programming, technology, finance, mathematical finance, etc. as subjects of discussion;
• to create an intellectually stimulating and social environment, where people can discuss about trends, problems, progress and achievements in any of the above-mentioned fields, in order to find what really matters in our work and discover how we can improve ourselves in a collaborative way.

The events will be organised in a relaxed way, with an informal pre-event drink, followed by the real event, and another social drink at the end. The real event includes (normally) two talks, with a short break in between, given by speakers in the software or finance industry. In this sense, the opening evening was an exception, having only one speaker for two sessions, with the additional honour to welcome the participants. Moreover, the social aspect of the event guarantees that the participants meet new people, thus creating a great opportunity to grow each other's network.

The talk on the opening evening was about test driven development (TDD) and test automation (mainly using NUnit and FitNesse), and the target audience was (and will be so also in the future) financial engineers as well as anybody else with a technical background. Testing is crucial in any product we build, as it helps us find errors, explore the parameter space of a method's arguments, but most importantly it sheds light about the code design.

TDD starts from a very simple idea: the test drives the development. Always write the test first and then add the code that makes the test pass. This is known as the red-green-refactor cycle and it is at the basis of TDD. You must repeat this cycle many many times, both to test each single method and to test the entire project.

In the simplest cases a test contains one or a few assertions. This is however not always true. For more complicated situations, one might find it useful to construct testing objects to save oneself a lot of work. Sometimes testing will look like doing research, because often the tester does not know a priori what the answer should be. A bit of creativity will help in those cases.

Coding (in C#, C++, Java, etc.) is by definition a technical job. Testing automation, however, is not, or.. it doesn't have to be. In order to test a function, you don't need to know the implementation details to figure out whether the output is correct or not. You only need a testing framework, which could be in principle anything. For instance, Excel will do (provided your favourite programmer friend has previously written for you an interface, or API, to translate your Excel methods into Excel functions).

FitNesse is one of the most popular testing frameworks around, and it has got the advantages of being light-weighted (it uses Wiki pages, which are very simple to write and edit), open source, and it runs on your localhost. It allows the user to set up test cases in an automated fashion, making your life as a tester easier and less painful than what it would be otherwise. Most importantly, FitNesse is a collaborative tool, where users, testers and programmers work together, and compares users' expectations with actual results from the code.

FitNesse supports many types of tests. In fact, it defines Fixture classes that correspond to different varieties of tests. For example, the column fixture class helps with repetitive tests, as it is the case when it is necessary to check the behaviour of a method against many values of its input parameters; the row  fixture class  takes care of comparing lists and it is very useful for databases.; and so on. In general, testing with FitNesse is easy, because FitNesse is able to automatically figure out input and output values, and even for forbidden inputs it will never crash but it always give report.

Here you can relive the opening evening by checking out the slides of the talk.

(Click any slide to start presentation mode)