Cleaning up log files for C++ Approval Tests

I wrote about the Gilded Rose kata a while back (https://barneydellar.blogspot.com/2020/07/gilded-rose-katas.html) and one thing I looked at was the use of Approval Testing to get the code under control. 

And I went further, and investigated using the same library to test logging behaviour. 

Approval Testing relies on consistent output given consistent input. But logging code typically adds the date and time to the log file. This is desired behaviour, but it makes testing against the log file hard.

The C++ Approval Test library (https://github.com/approvals/ApprovalTests.cpp) always had support for dealing with this, but it was quite verbose. You had to create a derived TextFileComparator, override the contentsAreEquivalent() method, and then use regex to find and replace the date and time with something hard-coded.

class SpdLogComparator : public TextFileComparator {
public:
    [[nodiscard]]
    bool contentsAreEquivalent(
        std::string receivedPath,
        std::string approvedPath
    ) const override {
        spdlog::shutdown();
        const auto new_contents = MungedFileContents(receivedPath);
        WriteFileContents(receivedPath, new_contents);
        return TextFileComparator::contentsAreEquivalent(receivedPath, approvedPath);
    }
private:
    [[nodiscard]]
    std::string MungedFileContents(std::string receivedPath) const {
        std::stringstream new_contents;
        std::regex word_regex("[.*] [(.*)] [(.*)] (.*)");
        std::smatch sm;
        std::string line;
 
        std::ifstream rstream(receivedPath);
        while (std::getline(rstream, line)) {
            std::regex_match(line, sm, word_regex);
            if (sm.size() >= 2) {
                new_contents << "[TIME_AND_DATE MUNGED BY TESTS] [" << sm[1] << "] [" << sm[2].str() << "] " << sm[3].str() << '';
            } else {
                new_contents << line << '';
            }
        }
        return new_contents.str();
    }
 
    void WriteFileContents(std::string receivedPath, std::string new_contents) const {
        std::ofstream fileout(receivedPath, std::ifstream::out);
        fileout << new_contents;
    }
};

This works, but it's quite long winded. 

You also needed to register an instance of the comparator in order to use it:

TEST_CASE("Test log") {
    FileApprover::registerComparator(".log", std::make_shared< SpdLogComparator>());
    WriteLog();
    Approvals::verifyExistingFile(log_file);
}

But now the library has been improved a lot, and this is all much simpler. 

You can now just create a function that will return an ApprovalTests::Scrubber or an ApprovalTests::Options instance. The scrubber does the work of replacing the text using a regex, and the Options can be obtained from it, in order to specify the file extension to work on. This can be done in just a handful of lines, with no boilerplate:

inline ApprovalTests::Options Munger() {
    const std::string dateRegex = "\\[[0-9]{4}-[0-9]{2}-[0-9]{2} [0-9]{2}:[0-9]{2}:[0-9]{2}.[0-9]{3}\\]";
    const std::string replacementText = "[MUNGED_DATE_TIME]";
    const auto munger = ApprovalTests::Scrubbers::createRegexScrubber(dateRegex, replacementText);
    return ApprovalTests::Options(munger).fileOptions().withFileExtension(".log");
}

And the use has been simplified too: 

TEST_CASE("Test log") {
    WriteLog();
    Approvals::verifyExistingFile(log_file, Munger());
}

This is a very nice improvement to the library, simplifying the test code a lot. Thanks to Clare Macrae for pointing this out to me :and helping me to get it working :-)

Comments

Post a Comment

Popular posts from this blog

We always start from where we are

Image
Earlier on in this year, I had a really interesting discussion online with Duncan Hothersall about Scottish Independence, and Brexit. I support independence, and Duncan very much doesn't. Scotland is currently about evenly split between supporters and opponents of independence, with a small number of hardcore unionists and nationalists on either side. But many people are in the middle, and weigh up the decision based on the perceived pros and cons. In itself, this disagreement between Duncan and myself is interesting. We share a similar world-view and similar hopes for the future. We agree in many ways on the kind of future we would like to see. But we disagree on how we want to get there.  This is of course a common pattern. We often share a purpose with other people, but we disagree on the tactics or maybe even the strategy for how to achieve it, and there is a wealth of literature on how to resolve such disagreements.  But what I found fascinating was how we both responded to B
Read more

Mobodoro

On our mob, we have started using the “ Mobodoro ” technique, which I picked up from Willem Larsen at Hunter.  The idea is based on the “ Pomodoro ” technique, where you do 25 minutes of solid work, then take a five minute break. And repeat.  But with Mobodoro, we have a couple of minutes to plan, then we do repeat mob rotations of 2 or three minutes, adding up to 25 minutes. Then we do a quick retrospective on the previous 25 minutes, have a quick break, and then repeat.  And for the break, we have a rule that we have to leave the mobbing area. Even if we just walk a few feet and back.  The retrospectives have been great. Often we have nothing. Because we’re only retrospecting on the previous half hour. But quite often we find something small we can change: a better way of using our whiteboard; a new chair; changing the mob rotation time; buying some Lego to keep track of our work.  The day seems to go much more smoothly, and at a much more sustainable pace. Two or three minutes brea
Read more

Instant Legacy Code

When we ran our recent Coderetreat, one session I really wanted to try was one I picked up from a workshop I did earlier in the year with Kevlin Henney and Jon Jagger. The basic idea is to show people  how quickly you can create Legacy Code.  We had a 45-minute session. For the first 20 minutes, we asked people to pair up, and solve Conway’s Game Of Life from scratch, with no other constraints.  But 20 minutes in, we asked one person from each pair to stand up and move to a different partner, and carry on.  Then, five minutes later we asked the other  person to move as well to a different partner again, and then carry on solving the problem. The code they encountered was only 25 minutes old, but everyone found it incomprehensible and convoluted.  We discussed it at a retrospective afterwards, and people were quite angry at the code they encountered, and at the people who’d left it (who were in the room with them!). And they felt guilty about walking away from such low quality solutions
Read more