Week 5: Testing Gnocchi!

I am currently not working on OpenSSL. Looking at old code was very tiring and hard to stay focused on, and I felt that I could be learning more by putting effort towards the Gnocchi side of things.

So with that, I figured the best thing I could do is to write tests for the publisher side of Gnocchi! While we don't have a spec, I can still get experience writing good tests. Honeyman once said that one thing that distinguishes UofM grads in the field is their ability to write good tests, so hopefully I can one day live up to that reputation.

I am using Google's C++ Testing Framework to make a test suite for Gnocchi.

Despite being ran from the command line, the output is neat and organized.

Google's C++ Testing Framework in action

Each one of these tests results in OK if the TEST() function returns without error and if each of the EXPECT*() functions result in true. For example, I can have a test as follows:

Test(basicTest, zero){
    int zero = 0;
    EXPECT_EQ(0, zero);
}

This test, if run, will return OK.

The testing framework also allows for EXPECT_THROW(). Basically, if the tested program throws a signal, we can catch it (if we are expecting a throw). If so, we are still OK.

Gnocchi, in its current iteration, is using Byte Vectors (which I think is fine, especially considering we don't really have a specification yet) to store data in memory. What this means is that for me to make unit tests on individual parts of Gnocchi, I have to EXPECT equality of vectors, which currently isn't supported by Google's code. Fortunately, I found a small extension to the testing framework that allows for EXPECT calls on containers that can be iterated (meaning vectors, of course).

The testing framework allows options such as --gtest_repeat=100 and --gtest_break_on_failure, which allow the user to customize his/her testing experience. For me, these options helped me find a bug in the wind() function in Gnocchi, which was removed in the next patch.

As Gnocchi continues to be modified, the tests created will have to change. That's fine for me, however, because I think I'm learning more about writing good tests that can be easily modified :). Unfortunately, I am still only writing unit tests. Probably this week, I will make higher-level tests that can also test to make sure we have expected behavior on the directory level. Further down the road, perhaps I can benchmark Gnocchi's sign/encrypt/decrypt/etc functions.


Misc:
I noticed Gnocchi was taking an abnormally long time to compile on my system, and I wanted to know why. My laptop's processor isn't the fastest (~2.66ghz Arrandale), but I even tried compiling on a desktop Haswell i7, which didn't result in much of a speedup. Part of the problem could be that I'm developing in a virtual machine (this is actually preferred for me because I have the best keyboard/mouse input that way). I give it 3gb memory (which should be enough?), 3 hyperthreaded cores, and it's stored somewhere on an SSD. But perhaps read/writes are not very fast on virtual machines. Perhaps compiling is more memory intensive than 3gb. Ultimately, however, there are (right now) many dependencies in each part of Gnocchi, which I learned contributes towards long compiling times; hopefully we can cut down on that and reduce compiling times in the future.