Posted by steve
on April 19, 2009
Earlier this month Steven Mak gave this presentation at the QCon conference in Beijing and having used that as a warm-up he is now ready to present Acceptance Test Driven Development to Agile Hong Kong:
Testing has always been the core part in software development but now it is no longer merely a tool for verification. Agile software development emphasizes “Quality Built In” and Acceptance Tests are becoming part of the requirement specification and the medium for customer collaboration. Acceptance Test Driven Development provides the methods for ensuring quality through customer collaboration. This talk will introduce the concept of ATDD and discuss how it works in practice. In particular, it will discuss two leading ATDD frameworks: FIT and Robot.
Steven Mak is an Agile Coach of Odd-e team. He is interested in different parts of software development activities and a variety of programming languages, from mainstream to the very exotic. At the moment, He focuses on the practice of test-driven development, refactoring, continuous integration, and also Scrum. He begins interested in programming while he was in primary school. Later obtained a Bachelor degree in Computer Science at the University of Hong Kong. To pursue better understanding of teams, customers, and products, he earned a Master degree in Business Administration from the Imperial College London. You can read more about his thoughts on his blog.
Don’t forget that pizzas and drinks will be provided before the talk and a small gift will be provided to all attendees!
Pizza will be sponsored by Pinpoint Asia.
Speakers reward for the night will be sponsored by JetBrains.
Location kindly provided by ThoughWorks.
When: 7:15pm, Wednesday 29th of April 2009
Where: ThoughtWorks Hong Kong Office
Address: Room 1304, 13/F, Tai Tung Building, 8 Fleming Road, Wanchai
Map: ThoughtWorks Hong Kong
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.