Per Otto Bergum Christensen

That’s the ambitious title of my presentation that I held at Statens Pensjonskasse on their agile day. Technical debt is a wide topic, so having an understanding of what it means is important before the discussion on how much can be started. I think the TechnicalDebtQuadrant is useful for introducing non-technical people to the different aspects of technical debt.

To justify taking up technical debt is easy, it could be what the project needs in order to be a success. Not solving all problems at once and focus on delivering customer value is a good agile tradition, and here is where technical debt in the form of shortcuts come in handy. The risk is that the shortcuts are too many, and decreases the quality so much over time, that the project could be held to a standstill.

So again, how much can be justified? Of course that answer can’t be given in numbers. I gave my audience two examples to consider. The first example contained a design shortcut where technical debt could be said to represent 50% of the initial budget. The other example represented a microscopic debt in comparison. So what was the conclusion about these two scenarios? It is not how much, but how it’s done, that is important.

In general I would suggest the following rules when considering technical debt:

1. Don’t take up a lot of small debt, the interest is high
2. Be careful, not every shortcut is a smart choice
3. Be methodical, debt should be paid
4. Be open about it, give the customer the right expectations about future maintenance and development

I have been working with BDoc for almost two years now. The characteristics of the work is that of R&D, small steps, all the time gaining more insight. The first public appearance of BDoc was on The Server Side 2008, in the article BDoc – Supporting Behavior-Driven Development. Since then I have developed BDoc further, and also getting valuable help from the community.

Micael Vesterlund joined the project after a while and has been the driving force behind the scenario support in BDoc. Espen Dalløkken had a dive in the codebase and changed the navigation principals from something that worked on paper to something that would work on the web.

After answering on a CfP at this years JavaZone I had a go with presentation driven development, promising a demonstration of BDoc with an application that should calculate pension for Norwegian citizens.

To view your work as a product that should be sold to an audience changes your mindset. Gone are the love of technical challenges buried in the code, features are the new vine, and I wanted them ready for the presentation. It kind of reminded me of a project several years back, where the customer announced that the software would be presented for its users, three months from the current date. They would be flown in from all over the country, and the airport hotel was already booked, the deadline was set.

Just like my older project I had to take up some deliberate technical debt to meet the deadline, prioritizing only functionality part of the demo. The debt is now paid and BDoc is again ready for new features, and also ready with it’s second demo, the game of yatzy. A snapshot is given below:

Just like Micael and Espen have joined the project, with comments and code, I would like to hear your opinion about BDoc. Code are always welcome, but comments are also something I value.

BDoc is installed as a maven plugin, if you are new to maven, all you have to do is to download it from http://maven.apache.org, and install it. To make it real easy to test BDoc I have made a zip out of the yatzy example. Download it, write mvn install in the project directory, and you will have the bdoc report generated in the directory target/site/bdoc.

There are some hidden links in the bdoc report, left overs from the presentation. Find them and you will see the code behind the documentation, just like in the snapshot.

My spam-filter is currently not working on my blog, but I appreciate any comments sent to perottobc@gmail.com.

Testing is more than verifying a set of requirements, in my view it is also a tool for having the code ready for change and new requirements. But it is also possible to end up down the wrong path, where tests works against change, by breaking all the time. Choosing the right tools and using them correctly is key when you want to embrace change.

At this years JavaZone I held a presentation about efficient testing. If you didn’t get to see me live you could check it out here (in norwegian).

That’s the name of the next open source project I’m getting into. It was started out by Espen Dalløkken in February 2008, as an investigation on part of the Live Cycle (LC) suite from Adobe Labs, called BlazeDS. It is open source and makes it real easy to integrate the client flex application with the server.

You can find the source code at http://just-blaze-ds.googlecode.com. 

Technology stack:

• Flex / Air
• Blaze DS
• Spring
• Hibernate
• HSQLDB
• Jetty

Of course this is a good opportunity to promote BDoc, so the application will be documented with user stories generated from the test code. Since functional testing of the GUI is a nice thing to support, we will add that as well. Hopefully with some help from the FunFX guys.  The GUI will also get an overhaul.

Read about BDoc on TheServerSide.com, and what other people have to say about it. Please join the discussion as well.

I had an interesting discussion about how to test applications through the user interface on JavaZone. I promised to sum up my experiences, so here it is:

Setup Page

Scenario: You have an application with a lot of pages and want to test something a page twelve.

First try: Make your GUI test tool fill out eleven pages and finally do your stuff at page twelve.

Consequence:

1. The test takes a long time to run, because of the eleven pages that needs to be filled out.
2. The test is fragile, because an error on any of the eleven pages will break the test
3. The test is a maintenance nightmare, changes in the chain of pages will require the test to be updated. A lot of tests like this will require a lot of unnecessary work.

Solution

Make a setup page in your application that can be used to generate test data. Rewrite the test so that it first uses the setup page to generate test data, and then takes the shortest route to page number twelve. The Mock Client pattern is a good starting point for implementing the setup page. By simulating a client directly against the service layer you also have a pretty nice integration test. It’s important that the mock clients run in Continuous Integration, if they break you want to know it as soon as possible. Remember to secure the setup page, so that it is unreachable in production.

Object per page

Scenario: You are starting out with automatic GUI-testing and are writing tests with the low level API that comes with the tool.

Problem: The the name of a button has changed and a lot of tests are breaking. Because the low level API has been used in different tests, we need to change the name of the button several places.

Solution: Make your own high level API of your application, on object per page. The page object could have methods like:

• page.go_to
• page.add_row( “col value 1”, “col value 2” )
• page.save

Result:

• The tests are easier to read
• The tests are faster to write
• A change in a page will only result in a change in the page object

Integration page

Problem: It’s difficult to run tests because other systems needs to be up and running and test data must be available and synchronised.

Solution: Make an integration page where you could change live integration points with mocks. When the tests run in Continuous Integration use mock integration, but keep the test data as close to live testing as possible. If key test data is equal in both live and mock testing, the tests can be reused for live testing. At the end of the iteration, turn to live integration, and run the tests to verify expected behaviour. Remember to secure the integration page, so that it is unreachable in production.

Words of advice

• Define a maximum test time for your suite, minutes are acceptable, hours are not
• The number of good tests are limited, to many tests will burden the project
• Keep track of tests that fails when the application isn’t broken, fragile tests belong in the garbage bin
• Migrate your tests into integration tests if you can, sounds difficult, but challenge yourself and the team. GUI testing is more expensive than integration testing.

Documentation will often be outdated the moment it has been written. Documenting is often considered to be a boring task as well. BDoc is a tool that produces documentation of the system from unit tests. When the a test change, the documentation will change. BDoc also supports Behaviour-driven development (BDD) and could be used to associate tests with user stories.

This talk is for you who have a need for updated documentation of a system. You could be a developer, tester or a responsible for the system being documented. BDoc could also be used to document behaviour that is unpractical to implement as functional acceptance tests.

BDoc is written for Maven2 and supports tests written in JUnit3, Junit4 and TestNG. Current version is 0.7.8 and is mature enough to use. Read more at http://bdoc.googlecode.com.

Read more about my norwegian talk here. 

BDoc is the name my open source project that extracts documentation from unit tests. The ‘B’ stands for behaviour and reveals that BDoc also is a tool for Behaviour-Driven Development (BDD). My goal is to promote Test First and let BDoc be the catalyst for test names that describes behaviour. BDoc itself doesn’t solve anything, it simply transforms the test code into documentation. How good this documentation is depends on what tests exists and how they are named.

Read more at http://bdoc.googlecode.com.