Two weeks ago I wrote an article about the virtues of sharing code in teams. Just to confuse you, this week I want to tell about a situation where code ownership actually helped me introduce a couple of agile engineering practices in a team I worked with some time years ago. Here's the story. Facts, names and situations have been twisted a bit to ensure the client's privacy.
The project
When I got started on this project the team had already been working on the code for some time. They didn't have strict rules about code ownership but most developers had started on their own piece of code at the beginning of the project and had kept on working in the code they knew as the project went on. When I joined the team everyone had a well defined layer of the application to call their own. I got to work on the UI layer.
On previous assignments I had tried introducing TDD and pair programming. But I often ran into problems. Maintaining a set of tests is hard when your co-workers change your code and don't fix tests when they break. You end up spending extra time fixing the tests other people break and it's hard to convince people to do TDD when it's costing you so much work.
Fresh off of a plane from attending Railsconf in Vegas, I feel really enthusiastic about where things are headed with Agile. The conference was well attended with upwards of 1200 developers most of whom are all familiar with Agile practices. And most of the developers I actually spoke to are either Scrum, XP or Scrum and XP shops.
It was also refreshing to know that what they appreciated most about Agile more than anything was the fact that it contributed positively to the quality of code that they were able to produce . This therefore segues nicely into the theme of my Blog post this week on how the role of QA Testers is expected to change on Agile projects.
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.
RSS feed
Subscribe on Kindle