Przejdź do głównej zawartości

Scripting paranoia

Jim is a developer in a team of nine and is better acquainted with Git than any of his colleagues. They rely on him when there is something particularly difficult to do with Git or if they have any kind of questions about Git. They feel comfortable asking him even the most basic questions, because Jim is so friendly and helpful.

Jim wants to make his teams' life easier so much that he creates a whole bunch of scripts. Over the course of time the team has a number of scripts that come in very handy when they want to perform regular, day-to-day versioning tasks:
  • branching: instead of regular Git commands -> branch.sh
  • merging: instead of regular Git commands -> merge.sh
  • tagging: instead of regular Git commands -> mktag.sh
  • pushing to remote server: instead of regular Git commands -> pushall.sh
  • viewing commit history: instead of regular Git commands -> showcommits.sh
  • and so on...
Scripts are well suited to what the team does daily. If there's the need to tweak any script a little, Jim is very willing to do so. Over the course of time, Jim's colleagues become so addicted to these scripts they cannot live without them. Unfortunately, they can no longer write proper Git commands or understand standard Git output on the console. How come they got into the mire, if they did all those things in order to become more efficient?

Obviously, it could be anything else, not neccesarily Git. My point is that any kind of computer system designed to interface with human beings, such as a version control system, presents to us its own mini-language, in the form of console commands or other, with which we can communicate with it. Its creators wanted us to communicate with it that way, it itself wants us to communicate with it that way. We should beware of encapsulating the sentences of this mini-language in scripts, because we will end up not being able to communicate with the system in any way that does not match any of our dozen of shortcuts. Not only will we be unable to issue any non-standard requests to the system, but we will also be unable to understand what it says to us.

Beware of scripting paranoia.

Komentarze

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:
        file.write(initials)

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
{
    public:

    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
{
    public:

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

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

    private:

    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
{
    public:
    virtual ~Generator() {}
    virtual Record * createNewRecord() = 0;
};

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

class MockGenerator : public Generator
{
    public:
    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())
        .Times(3)
                 //this is equivalent of returning new Record(1,2,3)
        .WillOnce(ReturnNew<Record>(1,2,3))
        .Will…