Archive for the ‘Continuous Integration’ Category

Re: The Future of Continuous Integration

Tuesday, May 1st, 2007

Paul Duvall’s post The Future of Continuous Integration points out a weakness in how continuous integration is typically implemented: code must be checked in before it is tested by the continuous integration server. Although problems are picked up fast, there is still a time window where developers may be affected by broken code. This is exactly why we added personal builds to Pulse in version 1.2. Personal builds allow individual developers to submit their changes to Pulse for testing before committing to version control. Pulse does a build and test of the latest version with the developer’s changes applied, allowing to developer to check the full impact of their changes prior to affecting the shared code base. Apart from closing the time window, personal builds also allow other powerful usage patterns, such as using the distributed building features of Pulse to test across multiple platforms before checking in.

Paul also touches on a couple of different solutions to the weakness. Naturally, before implementing personal builds as we did, we considered a few options. One option that Paul mentions that we had considered was leveraging the branching functionality of the SCM. Developers (perhaps with the assistance of the CI server) could check their code into private or temporary branches for testing, and the changes could then be merged down to the shared branch if the build passed. The main attraction of this method is that it reuses functionality available already in the SCM. However, we decided not to go down this route as it can have an impact on the way developers need to work and/or the structure and history in the SCM. Our method of taking a patch from the developer’s working copy and applying it directly with Pulse is about as unobtrusive as you can get. This is important for us, as the ability to adapt to existing environments has always been a key design goal for Pulse.

For more about these and related issues, you might want to also check out an article I posted a while ago to zutubi.com. Reducing the Impact of Broken Builds talks about the affects of a broken code base and how best to avoid or alleviate them.

Testing Is … A Worthy Challenge

Tuesday, April 24th, 2007

One of the reasons I love programming is that I enjoy the challenge of problem solving. On the flip side, nothing is more boring than repetitive, mind-numbing tasks. The great thing is that when something in my job becomes repetitive, that is a problem in itself that can be solved by programming. Meta.

Good developers don’t write the same five lines over and over, we abstract into a function. We abstract groups of functions (or objects) into libraries, and libraries into frameworks. Done right, we both take the tedium out of the job and enjoy the challenge of doing so. Then we get to enjoy the challenge of focusing on the real problems. If you like a challenge (and who doesn’t?), then you’re in the right place.

So why is it, then, that many developers avoid testing because they see it as a mind-numbing and repetitive activity? It is almost as if developers believe testing is an unskilled task that is doomed to be menial. In actual fact, testing takes many of the same skills as developing features. If you find it repetitive, ask yourself why and challenge yourself to do something about it. It is a perfect opportunity to put your problem solving skills to work.

Testing Is … Better Than Debugging

Thursday, April 5th, 2007

The Testivus “manifestivus” says Testing Beats Debugging:

We believe that time invested writing and running tests is better than time spent debugging.

The Google Testing Blog is headlined by a graphic that states:

Debugging Sucks. Testing Rocks.

I agree wholeheartedly. Debugging is a fact of development life1. It even has its own rewards, such as the sense of achievement when you find and squish a particularly nasty bug. Simply put, however, debugging is a massive waste of time2. Any time spent debugging could otherwise have been spent actually writing code, or otherwise being productive. Ergo, anything that helps to reduce the amount of time spent debugging is a Good Thing.

Testing reduces time spent debugging in various ways:

  • Well-crafted assertions in your tests will narrow bugs down right to the source. Operating at the unit test level in particular is more precise than manual testing.
  • Automated tests catch problems early in the development cycle, when they are easier to debug. It is well known that the earlier a problem is found, the easier it is to fix.
  • Regression tests catch problems that have been debugged before, so you don’t need to debug them again. This is particularly powerful in complex areas where bugs pop up frequently.

So, if you embrace testing, you can spend less time debugging and more time doing what you enjoy: writing great code ;).


1 At least until we start writing perfect code…
2 Note that is debugging, not using a debugger: they are quite different.

Testing Is … Good For Your Design

Thursday, March 29th, 2007

Fear not, despite the title I’m not going to start pontificating about design theory or TDD. Like always, the “Testing Is …” series sticks to straightforward ways in which tests make our lives easier. Being the lazy programmer that I am, I’m always looking for ways to make writing test cases easier. I suppose you might call this “designing for testability”.

Certain coding practices lead to code that is difficult to test: at best they make writing the tests painful, at worst they discourage testing and lead to maintenance pain down the track. The good news is that many of these practices are a sign of bad design in general, so by keeping testability in mind while you code you will often end up with a cleaner design. I look at it as the tests being a client of my code that help to keep the design honest.

An example is probably in order. First off, I find that it is unit tests that really drive the improved design. In unit tests we try to isolate a distinct piece (or “unit”) of code so that it can tested independently. The better we can isolate the units, the better we can cover the code as a whole without a combinatorial explosion in the possible inputs and outputs. The great thing is that well isolated units exhibit a key design practice: Separation of Concerns. To be truly isolated, a unit should be concerned with only one task. A complex system is much more powerful if it is built out of small, distinct units that can be combined in interesting ways (the “Unix way”).

A common counter-example that suggests testability and good design are actually competing goals is the apparent need to access internal unit state in tests. The problem with this of course is allowing the test to access that state is at odds with another key design practice: Encapsulation. In practice, I actually find that the need to access internal state is exceedingly rare. I would go so far as to say I consider it a design smell: if you feel the need to assert over some internal state in your tests, there is a good chance that the unit granularity is wrong (perhaps you have not truly separated concerns). There are exceptions of course, but in most cases refactoring is a better solution to subverting encapsulation. Thus, rather than countering, this example enforces that having test code as a client drives improvements to design.

Testing Is … A Huge Time Saver

Tuesday, February 27th, 2007

The most common excuse I have heard for the failure to write automated tests is that there is no time. People have a deadline to hit, and it seems there is no time to waste writing test code when there are features that need implementing. To me, this is a terrible excuse. Not because I think that code without automated tests can’t provide your customers with valuable features. Rather, it is because you are going to have to test the features somehow, and if you can’t do it automatically you are going to have to do it by hand. As I mentioned in a previous post, I think that in the majority of cases this will be slower than just writing the automated tests.

The crux of the argument is that features never work the first time that you try them. I don’t know about you, but when my new code works the first time I try it I’m not happy, I’m suspicious. This suspicion comes from years of getting things wrong. Typically, each feature will take several testing iterations to get right. This is trivial with an automated test, and time consuming with a manual one. I have not measured the typical time for each alternative, but I would say that most of us naturally assume the manual testing treadmill is less time consuming than it turns out to be1. So, when we have that short term deadline to hit, automating the tests can be a lot more effective at saving time than we realise.

Over the longer term, the fact that automated testing saves time is pretty much a no-brainer. In fact, I would say that this is just one case of a general principle:

Over the long term, the right way is also the fastest way.

Cutting corners is at best a near-term win, and cannot be sustained. Over the long term, automated testing continues to pay dividends, with only the (hopefully) small cost of maintaining the test suite. The most dramatic time savings come when your automated test suite finds a new bug as it is introduced by a developer. With the right process in place2, this bug can be fixed before it breaks the stride of the development team, and long before it reaches a customer and leads to a costly support incident.


1 Perhaps a specific case of the general optimism that makes most of us terrible at estimating software schedules.
2 And tools!

Testing Is … Freedom To Change

Wednesday, February 21st, 2007

For this second entry in the “Testing Is …” series, I decided to mention an advantage of testing that is widely known. The idea is not original, but its importance to you as a developer cannot be overstated. Perhaps the single greatest advantage of writing tests is the freedom you feel to change the code under test. All software grows cruft over time, and left unchecked the code will become an unmaintainable mess. Most developers would agree that maintaining code is not the greatest part of the job, and maintaining crufty code is about as bad as it gets. The answer is to refactor to remove the cruft over time. However, we also know from bitter experience that changing working code, no matter how crufty, will introduce new bugs1.

That is where the tests come in. If you have maintained a comprehensive test suite over time2, you need not fear nasty new surprises. You can refactor as required, and keep your code base much healthier. Now, test suites are not perfect and new bugs are still bound to happen. However, this is mitigated by two factors:

  • The difficulty in maintenance of the crufty code itself will lead to bugs.
  • A well-written test suite will cover those dark corners where bugs have been found to lurk. In particular, regression tests written to reproduce bugs as they are found are priceless at refactor time.

The logic is quite simple. Beyond that, there is also a powerful emotional difference. When the tests aren’t in place, we fear change. When we have the testing safety net, the fear is replaced with a sense of freedom. A freedom to change, and improve over time. A freedom which itself can be motivating.


1 If the cruft has grown due to the underlying complexity of the problem domain it is certain there are some nasty new bugs waiting for you!
2 Maintaining the tests as you write the code is important in itself. It is much more difficult to add tests later, not least because the problem is not fresh in your mind.

Wiki Syntax for Your Commit Comments

Wednesday, January 24th, 2007

Pulse has strong SCM integration, which includes showing changelist information for changes between builds. For some time, Pulse has had the ability to transform the commit comments that it displays to insert links to external systems. For example, you could link the text “bug 123″ to the summary for that bug in your issue tracking software. This is neat, as you can jump straight from Pulse to any external tool you choose to link to.

As part of Pulse 1.2, we have beefed up this system. One of our customers wanted to be able to strip redundant information from their commit comments as shown in Pulse. This led us to adding the ability to transform commit comments in more general ways than just linking. Now, you can specify an arbitrary regular expression to match and corresponding replacement text. The cool thing is that this mechanism gives you the power to do all sorts of useful transformations on your commit messages. It soon occurred to me that one very useful thing to do would be to support a Wiki-like syntax for your commit messages! For example, you can add a transformer to render text in bold when surrounded by asterixes:

Expression: \*([\w ]+)\*
Replacement: <b>$1</b>

The text between the asterixes is captured into group 1, and the replacement wraps this group with <b> tags. Now when viewing changes in Pulse, important bits stand out:

Of course, we can go much further. Linking is a good thing, so why not support turning anything that looks like a link into one? And anything that looks like an email address into a mailto: link? Here it goes:

Expression: http://[\w./]+
Replacement: <a href=”$0″>$0</a>

Expression: [\w]+@[\w.]+
Replacement: <a href=”mailto:$0″>$0</a>

Now whenever someone references a useful URL, it is but a click away from the Pulse web UI:

We have really just scratched the surface here. The mechanism is flexible enough to do all sorts of weird, wonderful and (hopefully) useful things! Give Pulse a try and go nuts!

New in Pulse 1.2: Integration with Fisheye/Trac/ViewVC

Thursday, January 11th, 2007

A great new feature we have introduced into Pulse 1.2 is tighter integration with change viewers. We have added simpler configuration for common viewers such as Fisheye, Trac and ViewVC (formerly ViewCVS), with custom configuration also possible for other systems. We have also deepened the integration by adding more direct links from Pulse back to your change viewer.

Now, when viewing changelist information in Pulse, you can directly access further information in your change viewer:

  • The changelist itself can be viewed in the change viewer by clicking on the revision wherever it appears in the Pulse UI.
  • Download and/or view the contents of any file as it was at the revision
  • Jump directly to the diff view in your change viewer to see what changes were made to a file.

The shot below shows how these links are presented for each file:

This feature is simple but incredibly useful. Figuring out why a build is broken often boils down to seeing what has changed. With change viewer integration, this information is at your fingertips. There is no need to change context. Enjoy!

UnitTest++: The New Choice for C++ Unit Testing?

Monday, December 18th, 2006

In an earlier post on C++ Unit Testing Frameworks, I came across a relatively new framework by the name of UnitTest++. At first glance, this framework appealed to me for a couple of reasons:

  • Unlike most of the other frameworks, it is relatively recent, and in development
  • One of the originators of the project is the author of the best comparison of C++ unit testing libraries online. The experience of reviewing several other frameworks should inform the design of a new framework.

So, I’ve decided to take a closer look. I’ll start in this post with the basics: how do we write tests, fixtures and suites in UnitTest++? These are the fundamentals of a unit testing library, and should be very simple to use.

First, we need the UnitTest++ distribution. It is available as a simple tarball from SourceForge. Exploding the tarball gives a basic structure with build files at the top level, and child docs and src directories. To build the library itself, on Linux at least, requires a simple make:

jsankey@shiny:~/tools/UnitTest++$ make
src/AssertException.cpp
src/Test.cpp

Creating libUnitTest++.a library…
src/tests/Main.cpp
src/tests/TestAssertHandler.cpp

Linking TestUnitTest++…
Running unit tests…
Success: 162 tests passed.
Test time: 0.31 seconds.

The primary output is libUnitTest++.a at the top level. This, along with the header files under src (excluding src/test), forms the redistributables needed to build against UnitTest++ in your own project. It is a little awkward that no binary distributions, nor a “dist” or similar Makefile target are available. However, the source tree is so simple that it is not hard to extract what you need.

Armed with the library, the next step is to create out first test case, and run it. UnitTest++ makes use of macros to simplify creating a new test case. It could hardly get an easier:

#include "UnitTest++.h"

TEST(MyTest)
{
    CHECK(true);
}

int main(int, char const *[])
{
    return UnitTest::RunAllTests();
}

A test case is created using the TEST macro, which takes the case name as an argument. The macro adds the test case to a global list of cases automatically. The body of the test utilises the CHECK macro to assert conditions under test. Various CHECK* macros are available for common cases. Finally, to actually run the test, we call UnitTest::RunAllTests(). This runs all cases using a default reporter that prints a result summary to standard output:

jsankey@shiny:~/repo/utpp$ ./utpp
Success: 1 tests passed.
Test time: 0.00 seconds.

RunAllTests returns the number of failed cases, so using this as the program exit code works well. If we change the check to CHECK(false), we get a failure report:

jsankey@shiny:~/repo/utpp$ ./utpp
utpp.cpp(9): error: Failure in MyTest: false
FAILURE: 1 out of 1 tests failed (1 failures).
Test time: 0.00 seconds.

The next step is to create a test fixture, which allows us to surround our test cases with shared setup/teardown code. This is achieved in UnitTest++ by building upon standard C++ construction/destruction semantics. To create a fixture, you just create a standard C++ struct. The setup and teardown code go in the struct constructor and destructor respectively. Let’s illustrate how this works:

#include <iostream>
#include <string>
#include "UnitTest++.h"

struct MyFixture
{
    std::string testData;

    MyFixture() :
        testData(“my test data”)
    {
        std::cout << “my setup” << std::endl;
    }

    ~MyFixture()
    {
        std::cout << “my teardown” << std::endl;
    }
};

TEST_FIXTURE(MyFixture, MyTestCase)
{
    std::cout << testData << std::endl;
}

int main(int, char const *[])
{
    return UnitTest::RunAllTests();
}

Instead of the TEST macro, we use TEXT_FIXTURE to create a test case that uses the fixture struct. The example is artificial, but serves to illustrate the order in which the functions are called. Also of interest is how members of the fixture struct are referenced directly by name within the test case. Under the covers, the TEST_FIXTURE macro derives a type from MyTestFixture, making this possible. Running this new program gives the following:

jsankey@shiny:~/repo/utpp$ ./utpp
my setup
my test data
my teardown
Success: 1 tests passed.
Test time: 0.01 seconds.

The setup and teardown wrap execution of the test case, which has simple access to the data in the fixture. By leveraging construction/destruction, the fixture code is both familiar and concise.

The final step is to organise test cases into suites. UnitTest++ again uses macros to simplify the creation of suites. You simply wrap the tests in the SUITE macro:

#include <iostream>
#include "UnitTest++.h"

SUITE(SuiteOne)
{
    TEST(TestOne)
    {
        std::cout << “SuiteOne::TestOne” << std::endl;
    }

    TEST(TestTwo)
    {
        std::cout << “SuiteOne::TestTwo” << std::endl;
    }
}

SUITE(SuiteTwo)
{
    TEST(TestOne)
    {
        std::cout << “SuiteTwo:TestOne” << std::endl;
    }
}

int main(int, char const *[])
{
    return UnitTest::RunAllTests();
}

As shown above, it is possible to have two tests of the same name in different suites. This illustrates the first function of suites: namespacing. Running the above gives:

jsankey@shiny:~/repo/utpp$ ./utpp
SuiteOne::TestOne
SuiteOne::TestTwo
SuiteTwo:TestOne
Success: 3 tests passed.
Test time: 0.01 seconds.

Suites also have another function: they allow you to easily run a group of related tests. We can change our main function to only run SuiteOne (note we also need to include TestReporterStdout.h):

int main(int, char const *[])
{
    UnitTest::TestReporterStdout reporter;
    return UnitTest::RunAllTests(reporter,
                                 UnitTest::Test::GetTestList(),
                                 “SuiteOne”,
                                 0);
}

Running this new main will only execute SuiteOne:

jsankey@shiny:~/repo/utpp$ ./utpp
SuiteOne::TestOne
SuiteOne::TestTwo
Success: 2 tests passed.
Test time: 0.00 seconds.

So there you have it, a taste of the basics in UnitTest++. The most appealing thing about this library is simplicity: you can tell that the authors have made an effort to keep construction of cases, fixtures and suites as easy as possible. This lets you get on with writing the actual test code. In this overview I have not explored all of the details, most notably the various CHECK macros that test for equality, exceptions and so on. However, as it stands UnitTest++ is quite a simple framework, and there is not a whole lot more to it. Although you may need more features than you currently get out of the box, UnitTest++ is young and thus I expect still growing. The simplicity also makes it an easy target for customisation, which is important given the diversity of C++ environments. I’ll be keeping an eye on UnitTest++ as it evolves, and recommend you take a look yourself.

AJAX Goodness in Pulse 1.2

Thursday, December 14th, 2006

Pulse has always used a bit of AJAX (and plain old JavaScript) here and there to make the interface more responsive. For example, there are plenty of instances where you can test new configuration before you save it, without leaving the configuration form (a huge time saver when configuring!). We also try to avoid gratuitous use of AJAX, which seems to be popping up all over the place as the hype takes its toll. However, in Pulse 1.2 we found some key places to introduce AJAX to give users that warm and fuzzy feeling.

My personal favourite is a new widget to customise the columns in build results tables. These tables are used to summarise the most important build information throughout the Pulse UI. Over time, our customers have requested several new pieces of information to be shown in the tables. Adding them all for everyone would lead to information overload, not to mention the required screen real estate. The obvious solution was to make the table columns customisable. This is a prime case where a rich client-side UI is far more usable than a “click-refresh-click-refresh…” approach. The widget we came up with is simple: a bunch of checkboxes to choose the columns to show, and the ability to drag and drop the columns to reorder them:

Using it is a snap, and it just Feels Good. Everything happens client-side until you apply and the changes take effect by an AJAX-refresh of the underlying page.

Another prime candidate for AJAXification was the views for browsing working copies and build artifacts. We already had a treeview in place for browsing directories (e.g. during the setup wizard), and with some work adapted it to these views:

I can not tell you how much faster it is to browse around using these views! The page only loads what is needed when you first hit it, and drilling down is much, much easier.