This training is for Google Test beginners and average users.

Have a nice read.

This training is for Google Test beginners.

Have a nice read.

#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!

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!

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.

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

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 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 .

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