Przejdź do głównej zawartości

The mythical independency principle

We're having a hypothetical conversation with Joe, a developer in a Scrum team.

- Joe, how is your team doing in terms of unit tests?
- Very good! We have a developer in our team, Jack, who is proficient in writing good unit tests. He works with other developers to understand what they are planning to implement and then writes dozens of unit tests that they can use to validate their work.
- Wait a minute, so he's the only one in the team who writes unit tests?
- Yes. That's his specialization. Because of this, not only is he able to write really good, maintainable tests, but is also so productive that an average of five tests per day is for him a piece of cake.
- But the unit tests aren't a separate development activity, they are integral part of developing the right code!
- This is what I used read on the Internet, but the reality is what we are doing here is in accordance with the independency principle.
- Tell me more about it.
- We are avoiding the Initial Error. If one developer writes the tests and another writes the implementation we know that they compared one thing against the other. If the same person would write the test and the implementation we would risk misinterpreting the requirements and doing wrong test for wrong implementation, with the test still passing.
- You must be kidding me (...)

OK, I could go on like this for hours. Remember: do not let anybody talk you into the Initial Error or Independent Unit Testing story. Consider the following short example, as an argument against views like those Joe presents.

You've bought one of these fancy new TV sets that can be hanged on the wall. In order to mount it, you need to mount a handle onto the wall. When the handle is mounted, the rest is simple - the TV set is compatible with the handle and you just put it on the handle. The trouble is, it takes more than one screw to mount the handle to the wall. How are you going to mount the handle so that it is in perfectly horizontal position? Use tape measure, perhaps? Or even a laser device to set the screws precisely? I might be a good idea, but our old friend Joe comes along and denies you the use of a tape measure, not to mention the laser. He says:

I will bring here a friend of mine with tape measure and the laser and once you are finished with the mounting he will measure it precisely to independently see whether your understanding of the word "horizontal" is same as yours.


Popularne posty z tego bloga

Unit Testing code with IO file operations (in Python)

We may often come across a piece of code that was written without Unit Tests at all. In addition, the piece of code may be dealing with IO like file writing and reading, which makes it more difficult to Unit Test it when we are trying to refactor and modify. Let's suppose the code in question looks like this:

def writeInitialsToFile(filename, name, surname):
    initials = name[0] + '.' + surname[0] + '.'
    with open(filename, 'w') as file:

def readInitials(filename):
    initials = None
    with open(filename, 'r') as file:
        initials = file.readline()
    return initials

A straightforward and bad idea would be to write a couple of Unit Tests that make use of a real file and simply test the reading and writing. Is therea a better way to test this code?

First of all, we need a way to replace the real file with something else. For both reading and writing we will now have a couple of functions, one that expects a stream fo…

Piotr's Less Obvious Advice on Google Mock: State maintenance

Google Mock provides several ways to maintain state inside mock objects. One way of implementing state maintenance is with SaveArg. Consider the following example.

We have a class Configurator, which allows a caller to set and get values of a parameter:

class Configurator

    virtual ~Configurator() {}

    virtual void setParamX(int n) = 0;
    virtual int getParamX() = 0;

And we have a class Client that calls Configurator's methods and it also has a method incParamXBy, that can be used to increase the current value of paramX by a certain value.

class Client

    Client(Configurator & cfg);
    virtual ~Client() {}

    void setParamX(int n);
    void incParamXBy(int n);
    int getParamX();


    Configurator & _cfg;

incParamXBy internally calls setParamX and getParamX on Configurator:

void Client::incParamXBy(int n)
    _cfg.setParamX(_cfg.getParamX() + n);

Let's assume that the initial value of paramX is A and that we want to increase paramX by…

Piotr's Less Obvious Advice on Google Mock: Returning new objects from a mock

Google Mock provides a way to return newly created objects from a mock method. Suppose we have a  Generator class that is supposed to generate new objects when createNewRecord method is called:

class Generator
    virtual ~Generator() {}
    virtual Record * createNewRecord() = 0;

...and suppose we want to mock this class:

class MockGenerator : public Generator
    MOCK_METHOD0(createNewRecord, Record * ());

Suppose the caller class Client has run method defined as follows:

void Client::run()
    for(int i = 0; i < 3; i++)
        rec_tab[i] = gen.createNewRecord();

We want the mock to return a pointer to a new object each time createNewRecord is called. This is how we can express this in the test code:

TEST(ClientTest, CanRun)
    MockGenerator gen;
    Client c(gen);

    EXPECT_CALL(gen, createNewRecord())
                 //this is equivalent of returning new Record(1,2,3)