Here at FundApps, we believe we are as much a Technology company as we are a Compliance company. One thing, in particular which we pride ourselves on and which separates us from the 'compliance norm' is our approach to testing - ensuring our software & rules are rigorously and automatically tested. Behind this we have a team of expert developers and compliance experts driving this.

For rule testing, we use Cucumber... or rather, Specflow - Cucumber for .Net.  OK, it isn't quite Compliance and Cucumber, more Compliance and Specflow but what's a blog without a silly title?

Plain English please, I hear you say. What is Specflow, what is cucumber if not simply a somewhat pointless if not deliciously refreshing vegetable?  And what do either have to do with compliance!?

SpecFlow is an open-source .NET tool which allows you to write Cucumber compatible Gherkin syntax. Yes, yes, another vegetable.  What a mouthful.  In a nutshell:  Gherkin is a computer programming language. It is however, written in plain (although, formatted) English. Cucumber is a platform which can interpret and execute these user-friendly, formatted English statements.

This is where Behaviour Driven Development (BDD) comes into its own. That Gherkin is written as a series of commands in plain English, allows for more user-focused scenario testing.

We are not considering whether a constructor finds a null parameter and throws an exception. We are testing real Business-user scenarios using a series of keywords which make up the foundations of the Gherkin syntax and BDD; given a particular portfolio, when a rule is run against it, then are my results as expected?

here’s an example:

1. Each rule is tested against a set of strict criteria, determined completely from an individual and specific use case.
2. Simple syntax – easy to understand and importantly, easy to see exactly (!) what is being tested and perhaps more importantly, exactly what is not.
3. Expressive test names are useful when tests fail.
4. Simple sentence test cases make tests focused

The crux of this is that our rule package is designed with end-user functionality at its core ensuring that the expected behavior is realised and rigorously examined.

And what’s the last step in this chain? Our rule updates are then subject to your approval. You have the final say and are free to query any of the decisions we have made.  You can now do this though, with the confidence that the rule has already passed a stringent set of use cases designed specifically to test some fixed use case.

All that and we haven’t even mentioned our integration tests… Watch this space!

Have a banana (banana for scale)