Today I have published first training from Agile C++ Developer series: Google Test – Introduction to asserts and expects. This is my first approach to this kind of training so every comments will be valuable.

This training is for Google Test beginners.

Have a nice read.

One of the most common problems in Test-Driven Development are parts of code which need to make some calls to your system environment. In general in such situation you are forced to use some global functions which are really hard to test or mock. So lets look on some code and lets try to make it more testable.

#include <fstream>
#include <string>

double calculate(const std::string& filepath) const
{
    std::ifstream file(filepath);
    double sum = 0;
    while (file.good())
    {
        double number;
        file >> number;
        sum += number;
    }
    return sum;
}

This is very easy piece of code – a function which calculates sum of doubles from given file. Code is easy but writing tests for it is rather hard… or maybe even impossible (well it is possible to test it using some preprocessor magic but this is my last resort).

We can split this code into some sections:

#include <fstream>
#include <string>

double calculate(const std::string& filepath) const
{
    // open file stream
    std::ifstream file(filepath);

    // load numbers from stream and calculate sum
    double sum = 0;
    while (file.good())
    {
        double number;
        file >> number;
        sum += number;
    }

    // return result, file is closed in destructor
    return sum;
}

We know that std::ifstream inherit from std::istream class. So we could rewrite this code as:

#include <fstream>
#include <string>

double calculate(const std::string& filepath) const
{
    // open file stream
    std::auto_ptr<std::istream> stream(new std::ifstream(filepath));

    double sum = 0;
    // load numbers from stream and calculate sum
    while (stream->good())
    {
        double number;
        (*stream) >> number;
        sum += number;
    }
    // return result, auto_ptr destructor destroy istream object
    // which destroys ifstream (virtual destructor)
    return sum;
}

We almost make our code free of calls to std::ifstream. The only thing left is creation of std::ifstream object. But we could refactor it to:

#include <fstream>
#include <string>

class FileSystem
{
public:
    virtual std::auto_ptr<std::istream> open(const std::string& filePath) const
    {
        return std::auto_ptr<std::istream>(new std::ifstream(filepath));
    }
};

class Calculator
{
public:
    Calculator(FileSystem* filesystem) : filesystem(filesystem) {}

    double calculate(const std::string& filepath) const
    {
        // open file stream
        std::auto_ptr<std::istream> stream = filesystem->open(filepath);

        double sum = 0;
        // load numbers from stream and calculate sum
        while (stream->good())
        {
            double number;
            (*stream) >> number;
            sum += number;
        }
        // return result, auto_ptr destructor destroy istream object
        // which destroys ifstream (virtual destructor)
        return sum;
    }

private:
    FileSystem* filesystem;
};

It is much better now! Code for calculate is free of global/static function calls so it is testable. The only think we have to do (to test calculate method) is to inject double of FileSystem (using polymorphism – then FileSystem::open method need to be virtual, or by making calculate method template – then dynamic polymorphism is not needed).

Of course we need to inject FileSystem in our production code but this is not as bad as someone may think. In my opinion it force programmer to think about design of his/her code instead of using global/static function calls where ever someone need to.

Above technique is called Dependency Injection (DI) and it is worth learning because it solves great number of problems when you have to make your code testable.

I hope you enjoy this reading… even if not I am waiting for your comments.

Happy testing!

When you are doing Test-Driven Development you try to test whatever you wrote. It is even better! You write tests before you write any line of code. But eventually when you have your brand new functions and classes (all 100% covered by tests) you have to integrate it in some working software. In the very end you have to write main(int, char**) function. How do you test it using Unit Tests?

Imagine that you have such easy (well known) application:

#include <iostream>

int main(int argc, char** argv)
{
    std::cout << "Hello World!" << std::endl;
    std::cout << "Number of arguments: " << argc << std::endl;
}

How would you test it using UnitTests? The easiest answer is that you cannot test it because there are no seam points which allow testing. It’s all true but I would like to show you that main() is testable… maybe not directly but you may transform above code with only little effort to something testable. For example you can do something like this:

#include <iostream>

class Main
{
public:
    static int main(int argc, char** argv)
    {
        std::cout << "Hello World!" << std::endl;
        std::cout << "Number of arguments: " << argc << std::endl;
        return 0;
    }
};

int main(int argc, char** argv)
{
    return Main::main(argc, argv);
}

It is much better now, isn’t it! At least we can call our main function in our tests! Unfortunately there are still some problems which will make testing of this a little pain. Our brand new Main::main function calls global objects which are always trouble for Unit Tests. But this also could be solved!

#include <iostream>

class Main
{
public:
    Main(std::ostream& output) : output(output) {}

    int main(int argc, char** argv)
    {
        output << "Hello World!" << std::endl;
        output << "Number of arguments: " << argc << std::endl;
        return 0;
    }

private:
    std::ostream& output;
};

int main(int argc, char** argv)
{
    Main app_main(std::cout);
    return app_main.main(argc, argv);
}

What we achieve is class Main which can be freely instantiate in any test we want. We could inject any kind of std::ostream to it (ie. std::stringstream) and test what was written to it. We may also manipulate with two arguments to check correct and invalid argument values. All of this is possible right now.

For those worrying about performance – modern compilers should compile our new code to the same binary as it would do for our previous version,  so don’t worry!

Happy testing!

Some time ago I was writing some piece of code in which there was a part where I have to concatenate strings differently depending on some flag. Easy thing. So I wrote some few lines of code and to my great surprise it does not work.

I wrote something like this:

<code class="cpp">bool flag;
/* ... some code setting flag ... */
std::string out = "path";
out += "/" + flag ? "X" : "Y";</code>

What I was trying to achieve is rather obvious but if you think that out string contains “path/X” or “path/Y” you are wrong! True is result was always “pathX”.

The reason for that is simple. Compiler (because of operator precedence) treats above code as:

<code class="cpp">out += ("/" + flag) ? "X" : "Y";</code>

instead of

<code class="cpp">out += "/" + (flag ? "X" : "Y");</code>

When I look at this bug right now it look easy, but I spend few minutes on few lines of code to catch it.

QPomodoro is tool which will help you in using The Pomodoro Technique™ in  your daily work . It is based on work done by Sakari Hyoty written for Nokia N900.  Current version was mainly developed on Windows and maybe it will not work properly on Nokia N900 or Linux (it will be done soon).

New features:

• QPomodoro has tray icon – application can be hidden in the tray.
• Time is displayed as window title so it is visible on task bar
• Tasks can be edited – name or estimate can be changed
• Order of tasks can be changed – task are movable using Drag & Drop
• Window icon is changed to “Pomodoro”
• On Windows added application icon.

New version can be downloaded from here: QPomodoro-0.4.1.zip

Source code can be cloned from here

I found very interesting video on Scrum Alliance web page. Lyssa Adkins (Certified Scrum Trainer, Project Management Professional  and Six Sigma Green Belt) presents scientific data about how positive psychology can improve your team. This is not wishful thinking but real science! Lyssa presents it clearly in her presentation (which is very good by the way) so take a look:

YouTube – Positive Psychology and Team Performance.

If you are interested in who is Lyssa and what is she doing you can go to her web page: http://www.coachingagileteams.com .

I was presenting Scrum as Agile method for project development on University of Technology in Wroclaw. During coffee break one of the students came to me and ask me a question about the Scrum Team, Product Owner and Scrum Master. During short discussion I compare Scrum Team to black box and I found it very interesting.

I don’t know why I use this comparison. Maybe just because during my studies on this university I spend lot of time working with black boxes (while I was studying robotics). Black box is something which has an input and output. You can’t tell what is going on inside that box but you can change input and check output. So, now imagine that (from Product Owner perspective) Scrum Team is like black box. Product Owner just gives Product Backlog Items and waits for the output. He or she doesn’t know (or at least should not care) what is going on inside the team. What is she or he interested in is just the output (which are Product Backlog Items done in the way Definition Of Done describes it).

What is more interesting on this black box there is a big red button which is called “Sprint reset” which can be used to reset team iteration. You can do it as you can do with your PC with the same result – everything which is in progress will be lost.

I found this picture very interesting and descriptive, what do you think about it? From my studies I know that we can connect controller (and also observer) with feedback loop to it which will allow you to control it with more precision. I am curious if this can be used to describe Scrum process… I have to think about it .

Today I found something interesting… it is called Sikuli and it is used for picture-driven programming. I know that it sounds silly but it is not! First thing is that guys from MIT are authors of this tool (language or programming style). The second thing is that it allows you (with little knowledge of python programming) to automate anything of your actions in Graphic User Interface – including operation with your operating system. The idea is: “If something is visible to user it can be programmed using sikuli!”.

I know that my description is rather poor and it doesn’t give you proper image of this tool… just take a look:

You can find more on http://sikuli.org

Have a fun (as I have) playing with this tool.

Changes in a system can be made in two primary ways. I like to call them “Edit and Pray” and “Cover and Modify”. Unfortunately, “Edit and Pray” is pretty much the industry standard.

Working Effectively with Legacy Code by Michael C. Feathers