Testing with mocks and stubs

Posted by Conrad Benham on October 14, 2008

On Thursday we took a further look at automated testing. A couple of months ago we had a Code Jam focused on Continuous Integration, in that session we looked at automating the build as a whole, including running tests. In our last Code Jam, we paid greater attention to testing and automating those parts of a system that rely on external or difficult to configure components.

In the session we looked at the differences between state based testing and interaction based testing including the pro’s and con’s of the two approaches. We identified why mock based testing makes unit testing easier and discussed the layering that tends to occur when using mock based approaches. Shen Tham drew an excellent comparison between stubs and mocks, briefly discussing the concept of Inversion of Control (IOC) and how it applies to mocking (this is something we’ll look at more closely in a future Code Jam). Aaron Farr also showed us how he uses mocks when testing the Model View Presenter pattern.

A reasonably simple example was used to demonstrate the use of Mockito. The example is a simple but incomplete graphing application that shows how data retrieved from a feed can be provided to something that can render it. The intent is to show how the various components can be split from each other in such a way that they an be unit tested separately from any live system that needs to be configured. If you take a look at the code you will see that the data used in the graph can be sourced from any appropriate system such as databases, file systems, FTP and HTTP. Likewise, it should be easy to see that the data can easily be displayed in a variety of ways. It can be written to a stream (as per the example code), written to file, sent to a browser via HTTP, published to an FTP server as a file, the options are open. It should be obvious that the feed and display are independent provided the common application interfaces are adhered to. While the mocking and stubbing techniques don’t enforce this, they certainly make help make it easier.

We looked specifically at the following Open Source Java mocking frameworks:

For other languages you might want to have a look at the following tools:

For further reading on Mocking I suggest the following:

In closing it is important to understand that an emphasis has been placed on testing at the unit level using mocks and stubs. There are many reasons for doing this. One must remember that unit testing alone is not sufficient to ensure complete and reliable integration with 3rd party systems. For this we must still write automated integration tests.  However, these tests can be isolated in such a way that they are only executed by the continuous integration environment if they take too long to execute on a developer machine. Unit tests written with mocks and stubs are therefore not a replacement for integration or functional tests.

Many thank to Kalun Wong for his summary of the evening’s activities.

Build Jamming

Posted by Conrad Benham on July 23, 2008

Builds are a fundamental part of any project. They are the bedrock of a project. Done well they make development and maintenance of a project easier. Done poorly and they can increase the time it takes to develop and maintain a project and even make development difficult. A well structured build will even help reduce defects by making continuous integration easier and by ensuring tests are run during each integration cycle. A good build will also aid in the deployment of a system.

In our next Jam we’ll look at build systems. Identify what makes a good build system, looking at how they might be structured for best practice. We’ll also look at various tools that support builds. Specifically we’ll look at tools that support continuous integration, prevent code duplication, bug detection and style checking amongst other tools. This Jam will include both a theoretical and a practical part. Some of the practices introduced in this session will form the basis to some future code jams.

So, dust your laptops off and come along. If you don’t have a laptop (or it doesn’t work) then come along anyway, we’ll work in pairs so there should be every opportunity for you to team up with someone. Don’t forget your laptop charger!

Drinks will be provided.

When: 7:30pm, Tuesday 29th of July 2008
Where: ThoughtWorks Hong Kong Office
Address: Room 1304, 13/F, Tai Tung Building, 8 Fleming Road, Wanchai
Map: ThoughtWorks Hong Kong
Contact

Agile at 10,000 feet 1

Posted by Conrad Benham on February 24, 2008

Agile Hong Kong is a new group, so it is fitting that one of the first informational postings be an introduction to Agile, related methodologies and principles. Here is a list of books, articles and websites containing information on some of the practices. This list is not definitive as there is much work out there dedicated to Agile – far more than could ever be captured here. The list should be a good start for those wanting to learn more about Agile.

All links open in a new window.

Methodologies

Agile is an umbrella term that is applied to a family or group of software development practices. Agile describes the practices that are generally applied by other methods including Extreme Programming, Crystal Clear, Scrum Alliance, Lean Software Development.

Extreme Programming

Lean Software Development

Crystal Clear

Scrum Alliance

Practices

Project Management

Stories, estimation and planning

Standups

Retrospectives

Sustainable Pace

Design

Testing

Pair Programming

Refactoring

Continuous Integration

Disclaimer: no royalties, benefits or bribes were solicited or received for any of the links contained in this list. No animals were hurt either.