SOA Contract Testing

One of the most important aspect of a SOA approach is testing. In order to get this right you should have several levels of tests, is very hard to match all things you should have just with unit tests.

If you think on abstractions a Service in Service Orientation(SO) it`s a composed by a service implementation and a contract.

A service could implement multiples contracts. I like to have one contract per service but there are scenarios where you could like to have more than one, for service aggregates or domain segregation cases.

So whats is a contract? For SOA contract is DATA, thats the real contract, but this could be seeing as many things, so i like to thing in some things to define what is the contract.  SOA is about Design so this could change depending of your main architecture design but in the way that i see it a contract would composed by the following elements.

Contract parts

1. Name (key identifiers, id, interface name, whatever that identify(unique) the service).
2. Access Point(uri, url, ip, whatever that points to the service)
3. Operations (names, inboud objects, outbound objects, interfaces, definitions, schema or schema -less)
4. Behavior (what the service does and how it does.
5. Protocol (REST?, Soap?, Rmi?, Ejb?, Http?)
6. Serialization Format (Xml, Json, binary, protocol buffers, stream, etc...)
7. Data Format (What is the date formats, list formats, specific data formats)
8. Transport/Media (Http, Rmi, Actors, js, java, memory, disk, ipc, etc..)

You will need to have contract test, so basically you will test this things. Your service might have different consumers, so the contract test will be great because you can also use him as backward compatibility test to make you dont break consumers with code changes and data changes.

Service operations could be very expensive, so i heavily recommend you do mock your dependencies and make contract test focused on just data. This could be hard so you need to have a great design in place, for service that are just data and very few business rules tests could be just check if the data is there and you might have mixed feelings but still better to have them nothing but you can judge if it worth while doing it or not.

Levels of Testing

Unit test is not enought, is hard to manage it and is hard to get proper feedback. You might see some overlap on my test levels, thats why you need to have clever engineering in order to reuse tests and change context so you create a solution where you inject fake mock or real objects to make tests become from contract to integration(3rd party dependency tests).

This will speed up development because you can use mocked data to Unit and Contract level so developers can run tests on they machines quickly and thats really important for XP developers.

Integration tests take time, same people have dedicated machines or jenkins replicas just to run this on separate threads since they will call databases, and other heavy services you might have. Interoperability are important for external consumer or for the cases you have different parts of your business or partners coding with different languages so you need make sure stuff works in other langs. REST and JSon can be very trick, so i recommend you have some of this tests.

A Great why to Do BDD?

The best spot to do BDD in SOA for me in not the Unit but the Contract, so you can do something like TDC, Test Contract Development and write tests in formars of specifications using stuff like cucumber or specs 2 this is great because it make it clear what the services does and people that are less technical can check just one place to understand the whole service.

Why is important talk about contracts?

In SOA, Services are citizen of first class. So you need to balance what goes to Services(contracts), Apps, Applications and UI. So you need establish concerns and profiles for services and that you make you able to think about features and decide what put where. 

I see contracts as a kind of reflect of the real business, software architecture is bound to the business constraints, so you need to have business people involved on contract definitions and development and this is not something static, is something that never stops , you always need keep having discussions in order to make sure you keep doing right decisions.

Cheers,