In this eleven minute tutorial I'm presenting TDD with mocking technique using JUnit 4.x and EasyMock library. This is more advanced example of Test Driven Development - video tutorial on basics can be downloaded from here: Test Driven Development in practice.
Source code for this tutorial can be downloaded here (you can find also Eclipse project files in this bundle, so it's easy to import the project directly to your IDE - NetBeans users have to create a new project and add relevant classpath changes). Note that external.jar was built with Java 6 and thus you have to use at least JDK version 6 to be able to compile and run the example.
In this nine minute tutorial I'm presenting TDD way of developing software i.e. start from writing the test.
Many people often say that you should start from implementing at least interface and then start testing. In this tutorial I'm showing how easy it is to start writing unit test with nothing (not even an interface) i.e. only having the requirements. After couple of minutes I've got an interface, a working implementation and a full test suite.
This is what Test Driven Development is all about - software should be developed this way. Open this article to see the bigger player.
Methods & Tools is a free e-newsletter for software developers, testers and project managers. Summer 2008 issue's content:
* UML versus Domain-Specific Languages
* We Increment to Adapt, We Iterate to Improve
* Building Products with Acceptance TDD
* Getting and Keeping Control over your Project
I'm an agile developer because I write my code incrementally i.e. only what I need today. I usually start writing the code by writing Unit Test - it really works and it really helps me understand what should be implemented and how system should behave (I will leave the subject of convincing people, who are new to unit testing, to do "write-test-first" for a separate post). OK - I usually do this but sometimes it's difficult or I'm just too impatient to see the result and start with the implementation and write unit test later. How do I know which packages/classes/methods are tested and which are "not touched" by any single unit test? How do I know that my code is really used somewhere by other parts of the developed system? This is the work for code coverage tool.
Test-First Programming (TFP) and its sometimes more known related practice Test-Driven Development(TDD) are not very usual for the traditional software development cycle. Test-driven development simply means creating tests before writing the code they are supposed to test. A canonical test-driven cycle is as follows:
Write a test for the functionality you are going to implement
Write as little code as possible to make the test compile. Make sure that at this step the test fails
Write minimal or almost minimal code needed to make the test pass
Once the test passes, refactor the code to make it better, prettier or simpler. The test and other existing tests will guard against accidental functionality breaks during the refactoring process
Update: The users of some a bit exotic SDKs reported that they cannot build the example. The reason was the project file SampleTest.mmp. I updated it making the project file a bit redundant. Now example should be compilable on any S60 SDK.
CppUTest is a unit testing framework based on CppUnitLite and designed for the embedded systems usage. Lately it has been ported to Symbian OS used in Nokia S60 smartphones. The framework is xUnit compatible, extremely simple and easy to use. It can print the test results both to console and to a junit-like xml file (later I am going to investigate how well it can be parsed by standard junit output parsers).
Symbian extension. Usage example
Unfortunately, CppUTest package at the moment does not include a full-blown Symbian specific example and lacks support for such Symbian primitives as descriptors (Symbian strings) and leaves (Symbian exceptions).
The file attached to this post contains both. It is a simple and heavily commented example of using CppUTest in Symbian, that includes cpputestsymbianextension.h adding support for descriptors and leaves.
A colleague of mine lately asked me what would be the most important C++ IDE features for supporting the agile software development. While agile processes are more about people and interaction, than about the tools, a decent tool support certainly makes things easier. Here is a list of things I would value in the agile-aware C++ IDE in the order of decreasing priority.
1. Command-line repeatability Agile methods see the high levels of automation of a ‘mechanical’ and repetitive tasks as a relief for the developers and help to reduce errors.
Anssi Piirainen raises the idea about the need to be good at being wrong in order to create good software. The core idea is good - you have to be ready that the first implementations might later look not very well. However, Anssi also presents the micro case study describing the problems with the "just-in-time design" approach. The changes required appeared to be unexpectedly difficult to not that experienced programmers.
Just-in-time design is not a silver bullet. It is just yet another good tool that can be rather useless until it is used with the correct support practices.
I am rather new to the Test-Driven-Development (TDD) and continuous testing in general. Therefore I quite often experience the terminology difficulties: how to call fully functional alternative object, how to call almost empty stub objects, etc. It looks like I am not alone.
The generic term he uses is a Test Double (think stunt double). Test Double is a generic term for any case where you replace a production object for testing purposes. There are various kinds of double that Gerard lists:
RSS feed