This article presents two approaches of how TDD can be applied. The first is the classic one where the objects are treated as black-boxes and verification is based on the objects state. The second one is focused on interactions.
Have you ever worked on a project where after downloading the code from the repository you start to wonder what business requirements are hidden under the layer of unreadable tests? Or maybe you are currently wondering how to test a new feature that you have been entrusted to implement?
SOA (Service Oriented Architecture) as a modern approach to build distributed enterprise applications gives us many benefits, including resiliency and fault-tolerance. On the other hand, there are many new kinds of SOA-specific faults, like publishing, discovery, composition, binding or execution faults (as stated in A Fault Taxonomy for Service-Oriented Architecture). Error handling is one of the most important things to have services right designed and implemented (see article Error Handling Considerations in SOA Analysis & Design). In this article, I want to focus only on a small aspect of this broad subject: unexpected service behaviors which, if not properly handled by the client, can lead to application inaccessibility.
On January 30th we made a visit to GeeCon TDD to find out what’s going on in the world of TDD. Allegro was one of the sponsors of the event and our colleague Piotr Betkier appeared as a speaker. The theme of the conference was the broad subject of software testing and TDD. The question for the conference to answer was “Is TDD dead?”. The major stars who came to Poznań were Nat Pryce and Steve Freeman, authors of the book “Growing Object-oriented Software, Guided by Tests”.
