{"id":1186,"date":"2013-08-09T01:00:00","date_gmt":"2013-08-08T23:00:00","guid":{"rendered":"https:\/\/www.fussylogic.co.uk\/blog\/?p=1186"},"modified":"2013-08-09T14:23:03","modified_gmt":"2013-08-09T13:23:03","slug":"fizz-buzz-testing","status":"publish","type":"post","link":"https:\/\/www.fussylogic.co.uk\/blog\/?p=1186","title":{"rendered":"Fizz Buzz Testing"},"content":{"rendered":"

Unit testing is the name we give to the idea of writing code that tests our application code automatically. Essentially, its job is to exercise each piece of your application in isolation, and ensure that any data dependent bugs you might introduce accidentally, never make it into production releases. Personally, I also find it makes programming more enjoyable; it takes your large application and lets you play with just a little piece of it \u00e2\u20ac\u201c programming becomes more like a little bite sized puzzle. That being said, it\u00e2\u20ac\u2122s not always easy to write test code, especially in large intricate libraries you will find you have to start faking<\/a> parts of the system to feed to your test code. I\u00e2\u20ac\u2122m not going to go into that today.<\/p>\n

I used to do my unit testing like this:<\/p>\n

#ifdef UNITTEST<\/span>\nint<\/span> main()\n{\n    try {\n        \/* tests *\/<\/span>\n    } catch( exception &e ) {\n        log() << e.what() << endl;\n        return<\/span> 255<\/span>;\n    }\n}\n#endif<\/span><\/code><\/pre>\n
Now, I could just give you my boilerplate template, but I thought it would be nice to actually show you it in use on something real. So, let\u00e2\u20ac\u2122s attack the problem that 199 out of 200 applicants for developer positions<\/a> can\u00e2\u20ac\u2122t do (incidentally that doesn\u00e2\u20ac\u2122t mean if you can<\/em> do this you\u00e2\u20ac\u2122re in the top 0.5%<\/a>) and unit test the result with cppunit. That problem is FizzBuzz<\/a>.<\/p>\n
\n
Write a program that prints the numbers from 1 to 100. But for multiples of three print \u00e2\u20ac\u0153Fizz\u00e2\u20ac\u009d instead of the number and for the multiples of five print \u00e2\u20ac\u0153Buzz\u00e2\u20ac\u009d. For numbers which are multiples of both three and five print \u00e2\u20ac\u0153FizzBuzz\u00e2\u20ac\u009d.<\/p>\n<\/blockquote>\n
First let me say this: a lot of good programmers, who can do this test, for a bit of fun coded up elaborate and clever solutions. For fun, that\u00e2\u20ac\u2122s fine, but clever solutions make for poor, unreadable, code. I\u00e2\u20ac\u2122ll not bother with anything clever then, I\u00e2\u20ac\u2122ll just do a work horse solution.<\/p>\n
void<\/span> FizzBuzz() {\n    for<\/span>(int<\/span> i = 0<\/span>; i <= 100<\/span>; i++) {\n        bool f = (i % 3<\/span>) == 0<\/span>;\n        bool b = (i % 5<\/span>) == 0<\/span>;\n        if<\/span>(f)\n            cout << "Fizz"<\/span>;\n        if<\/span>(b)\n            cout << "Buzz"<\/span>;\n        if<\/span>(!b && !f)\n            cout << i;\n        cout << endl;\n    }\n}<\/code><\/pre>\n
This solution is rubbish. It\u00e2\u20ac\u2122s not rubbish because it doesn\u00e2\u20ac\u2122t work, or because it\u00e2\u20ac\u2122s not a clever solution, it\u00e2\u20ac\u2122s rubbish because to test it we have to run it then manually eyeball 100 lines of output \u00e2\u20ac\u201c worse, what if it was 1000 lines of output? That means it\u00e2\u20ac\u2122s difficult to test.<\/p>\n
That difficulty represents a smell from our code. Well written code will<\/em> be testable. Let\u00e2\u20ac\u2122s first split it into something that\u00e2\u20ac\u2122s testable by separating our maths from our loop.<\/p>\n
enum<\/span> class eFizzBuzz {\n    Null,\n    Fizz,\n    Buzz,\n    FizzBuzz,\n};\n\nostream &operator<<(ostream &s, eFizzBuzz fb)\n{\n    switch<\/span>(fb) {\n        case<\/span> eFizzBuzz::Fizz:\n            return<\/span> s << "Fizz"<\/span>;\n        case<\/span> eFizzBuzz::Buzz:\n            return<\/span> s << "Buzz"<\/span>;\n        case<\/span> eFizzBuzz::FizzBuzz:\n            return<\/span> s << "FizzBuzz"<\/span>;\n        case<\/span> eFizzBuzz::Null:\n            return<\/span> s << "Null"<\/span>;\n    }\n}\n\neFizzBuzz FizzBuzz(int<\/span> n)\n{\n    bool f = (i % 3<\/span>) == 0<\/span>;\n    bool b = (i % 5<\/span>) == 0<\/span>;\n    if<\/span>(f && b)\n        return<\/span> eFizzBuzz::FizzBuzz;\n    if<\/span>(f)\n        return<\/span> eFizzBuzz::Fizz;\n    if<\/span>(b)\n        return<\/span> eFizzBuzz::Buzz;\n    return<\/span> eFizzBuzz::Null;\n}\n\nvoid<\/span> FizzBuzz() {\n    for<\/span>(int<\/span> i = 0<\/span>; i <= 100<\/span>; i++) {\n        auto<\/span> fb = FizzBuzz(i);\n        if<\/span>(fb == eFizzBuzz::Null) {\n            cout << i << endl;\n        } else<\/span> {\n            cout << fb << endl;\n        }\n    }\n}<\/code><\/pre>\n
A lot more code; and you might say \u00e2\u20ac\u0153how is more code better, if it does the same job?\u00e2\u20ac\u009d. The answer is that it does the same job only superficially. Writing testable code has forced us to write cleaner, more general code. We\u00e2\u20ac\u2122ve separated our algorithm from our application, and we\u00e2\u20ac\u2122ve also generalised our output.<\/p>\n
This is now in a form that we can write a unit test. Let\u00e2\u20ac\u2122s do so. Make sure you have the cppunit<\/code> library available (apt-get install libcppunit-dev<\/code> on Debian).<\/p>\n
First the test case, note there is absolutely no requirement that this go in the same module as the code it\u00e2\u20ac\u2122s testing. I like to do that and keep my test code wrapped in #ifdef UNITTEST<\/code>, but you can do as you wish.<\/p>\n
#include <cppunit\/extensions\/HelperMacros.h><\/span>\n\nclass FizzBuzzTest : public CppUnit::TestFixture\n{\n  public:\n    void<\/span> setUp(void<\/span>) {}\n    void<\/span> tearDown(void<\/span>) {}\n\n    void<\/span> test_fizzbuzz() {\n        CPPUNIT_ASSERT_EQUAL(eFizzBuzz::Fizz, FizzBuzz(3<\/span>));\n        CPPUNIT_ASSERT_EQUAL(eFizzBuzz::Buzz, FizzBuzz(5<\/span>));\n        CPPUNIT_ASSERT_EQUAL(eFizzBuzz::FizzBuzz, FizzBuzz(15<\/span>));\n    }\n\n    \/\/ -----------------------<\/span>\n\n    \/\/ HelperMacros to manufacture `static CppUnit::Test *suite()`<\/span>\n    CPPUNIT_TEST_SUITE(FizzBuzzTest);\n    CPPUNIT_TEST(test_fizzbuzz);\n    CPPUNIT_TEST_SUITE_END();\n};\n\/\/ Add manufactured FizzBuzzTest::suite() to the global test<\/span>\n\/\/ register<\/span>\nCPPUNIT_TEST_SUITE_REGISTRATION(FizzBuzzTest);<\/code><\/pre>\n
cppunit<\/code>\u00e2\u20ac\u2122s helper macros, while slightly unnerving looking, are straight-forward to use. Everything in the top half is just a standard class derived from CppUnit::TestFixture<\/code>, setUp()<\/code> and tearDown()<\/code> are called before and after each test \u00e2\u20ac\u201c these supply a clean environment for each test to run in; we\u00e2\u20ac\u2122re not using them here. test_fizzbuzz()<\/code> is arbitrarily named, and is added to the list of tests (cppunit<\/code> calls it the test suite) in this class with the CPPUNIT_TEST(test_fizzbuzz)<\/code> line. The test suite represented by this class is then scheduled for test with CPPUNIT_TEST_SUITE_REGISTRATION(FizzBuzzTest)<\/code>.<\/p>\n
Now we just need the code to run the tests.<\/p>\n
#include <cppunit\/ui\/text\/TestRunner.h><\/span>\n#include <cppunit\/TextOutputter.h><\/span>\n#include <iostream><\/span>\n#include <stdexcept><\/span>\nint<\/span> main()\n{\n    \/\/ --- Boilerplate cppunit code<\/span>\n    \/\/ Set up runner to run all test in registry<\/span>\n    CppUnit::TextUi::TestRunner runner;\n    runner.addTest( CppUnit::TestFactoryRegistry::getRegistry().makeTest() );\n    \/\/ Redirect output to clog,<\/span>\n    runner.setOutputter(new CppUnit::TextOutputter(&runner.result(), std::clog));\n    \/\/ Run all and give success indiciation<\/span>\n    return<\/span> runner.run() ? 0<\/span> : 1<\/span>;\n}<\/code><\/pre>\n
Thanks to the use of the test registry there is absolutely no code in this block specific to our tests \u00e2\u20ac\u201c you can use this without change in every single project you have. It runs every test suite registered, outputs to std::clog<\/code> (stderr) and returns 0 for test success, and 1 for test failure \u00e2\u20ac\u201c this is typical for command line programs.<\/p>\n
The meat of our unit test is in test_fizzbuzz()<\/code>, and we are free to do anything we wish. The most useful thing we can do though is to use the cppunit<\/code> assertions to perform some tests.<\/p>\n
void<\/span> test_fizzbuzz() {\n    CPPUNIT_ASSERT_EQUAL(eFizzBuzz::Fizz, FizzBuzz(3<\/span>));\n    CPPUNIT_ASSERT_EQUAL(eFizzBuzz::Buzz, FizzBuzz(5<\/span>));\n    CPPUNIT_ASSERT_EQUAL(eFizzBuzz::FizzBuzz, FizzBuzz(15<\/span>));\n}<\/code><\/pre>\n
CPPUNIT_ASSERT_EQUAL()<\/code> takes two arguments, expected<\/code>, and result<\/code>. cppunit<\/code> expects to be able to output both of these to a stream should the test fail, so our operator<<()<\/code> implementation for eFizzBuzz<\/code> types is a necessity here.<\/p>\n
Here\u00e2\u20ac\u2122s my compile and build:<\/p>\n
clang++ -ggdb3 -O2 -Wall -Wextra -std=c++11 -Wfatal-errors   -c -o fizzbuzz.o fizzbuzz.cc\nclang++ -pthread -rdynamic -lcppunit   -o fizzbuzz fizzbuzz.o\n.\n\n\nOK (1 tests)<\/code><\/pre>\n
cppunit<\/code> output is terse when there are no failures. It\u00e2\u20ac\u2122s expected that there will be a great many tests for a project, and it\u00e2\u20ac\u2122s far better to have only the failures show any verbose output. The \u00e2\u20ac\u0153.\u00e2\u20ac\u009d indicates a test ran, and the summary tells us everything was okay with 1 tests<\/code> run.<\/p>\n
Our tests as they stand are not very good. We\u00e2\u20ac\u2122ve made the classic mistake of only testing for the match cases, not for the non-match cases.<\/p>\n
void<\/span> test_fizzbuzz() {\n    CPPUNIT_ASSERT_EQUAL(eFizzBuzz::Null, FizzBuzz(0<\/span>));\n    CPPUNIT_ASSERT_EQUAL(eFizzBuzz::Null, FizzBuzz(1<\/span>));\n    CPPUNIT_ASSERT_EQUAL(eFizzBuzz::Null, FizzBuzz(2<\/span>));\n    CPPUNIT_ASSERT_EQUAL(eFizzBuzz::Fizz, FizzBuzz(3<\/span>));\n    CPPUNIT_ASSERT_EQUAL(eFizzBuzz::Null, FizzBuzz(4<\/span>));\n    CPPUNIT_ASSERT_EQUAL(eFizzBuzz::Buzz, FizzBuzz(5<\/span>));\n    CPPUNIT_ASSERT_EQUAL(eFizzBuzz::Null, FizzBuzz(6<\/span>));\n    CPPUNIT_ASSERT_EQUAL(eFizzBuzz::Null, FizzBuzz(7<\/span>));\n    CPPUNIT_ASSERT_EQUAL(eFizzBuzz::Null, FizzBuzz(8<\/span>));\n    CPPUNIT_ASSERT_EQUAL(eFizzBuzz::Null, FizzBuzz(9<\/span>));\n    CPPUNIT_ASSERT_EQUAL(eFizzBuzz::Null, FizzBuzz(10<\/span>));\n    CPPUNIT_ASSERT_EQUAL(eFizzBuzz::Null, FizzBuzz(11<\/span>));\n    CPPUNIT_ASSERT_EQUAL(eFizzBuzz::Null, FizzBuzz(12<\/span>));\n    CPPUNIT_ASSERT_EQUAL(eFizzBuzz::Null, FizzBuzz(13<\/span>));\n    CPPUNIT_ASSERT_EQUAL(eFizzBuzz::Null, FizzBuzz(14<\/span>));\n    CPPUNIT_ASSERT_EQUAL(eFizzBuzz::FizzBuzz, FizzBuzz(15<\/span>));\n}<\/code><\/pre>\n
This might look odd, as programmers we\u00e2\u20ac\u2122re used to turning sequences like this into a loop; but remember what we\u00e2\u20ac\u2122re testing is pretty fundamental \u00e2\u20ac\u201c whether we\u00e2\u20ac\u2122ve used C++\u00e2\u20ac\u2122s modulo operator correctly. It would be a pretty bad test then if we used the very thing we were testing in our test \u00e2\u20ac\u201c that\u00e2\u20ac\u2122s like saying \u00e2\u20ac\u0153if(testresult == testresult)<\/code>\u00e2\u20ac\u009d. Our only option then is to hard code tests without using \u00e2\u20ac\u0153%<\/code>\u00e2\u20ac\u009d and a loop counter. This is the equivalent of us eyeballing every line of output from the first example.<\/p>\n
Let\u00e2\u20ac\u2122s run our test again\u00e2\u20ac\u00a6<\/p>\n
clang++ -ggdb3 -O2 -Wall -Wextra -std=c++11 -Wfatal-errors   -c -o fizzbuzz.o fizzbuzz.cc\nclang++ -pthread -rdynamic -lcppunit   -o fizzbuzz fizzbuzz.o\nrm fizzbuzz.o\n.F\n\n\n!!!FAILURES!!!\nTest Results:\nRun:  1   Failures: 1   Errors: 0\n\n\n1) test: FizzBuzzTest::test_fizzbuzz (F) line: 97 fizzbuzz.cc\nequality assertion failed\n- Expected: Null\n- Actual  : FizzBuzz<\/code><\/pre>\n
Very useful, we\u00e2\u20ac\u2122ve already caught something. A test failure when \u00e2\u20ac\u0153null\u00e2\u20ac\u009d was expected but the result was \u00e2\u20ac\u0153fizzbuzz\u00e2\u20ac\u009d (we\u00e2\u20ac\u2122re seeing the advantage of our operator<<()<\/code> in this output). You can\u00e2\u20ac\u2122t see my line numbers of course, but this is the faulty line:<\/p>\n
    CPPUNIT_ASSERT_EQUAL(eFizzBuzz::Null, FizzBuzz(0<\/span>));<\/code><\/pre>\n
Spotted the fault? It\u00e2\u20ac\u2122s actually a fault in our test. Zero is divisible by 3 and by 5 and by everything in fact. The expected output is therefore \u00e2\u20ac\u0153FizzBuzz\u00e2\u20ac\u009d not \u00e2\u20ac\u0153Null\u00e2\u20ac\u009d.<\/p>\n
We\u00e2\u20ac\u2122ve also only tested from 0 to 15 so far; we should do more:<\/p>\n
void<\/span> test_fizzbuzz() {\n    for<\/span>( int<\/span> i = 0<\/span>; i < 1000<\/span>; i += 15<\/span> ) {\n        CPPUNIT_ASSERT_EQUAL(eFizzBuzz::FizzBuzz, FizzBuzz(i + 0<\/span>));\n        CPPUNIT_ASSERT_EQUAL(eFizzBuzz::Null, FizzBuzz(i + 1<\/span>));\n        CPPUNIT_ASSERT_EQUAL(eFizzBuzz::Null, FizzBuzz(i + 2<\/span>));\n        CPPUNIT_ASSERT_EQUAL(eFizzBuzz::Fizz, FizzBuzz(i + 3<\/span>));\n        CPPUNIT_ASSERT_EQUAL(eFizzBuzz::Null, FizzBuzz(i + 4<\/span>));\n        CPPUNIT_ASSERT_EQUAL(eFizzBuzz::Buzz, FizzBuzz(i + 5<\/span>));\n        CPPUNIT_ASSERT_EQUAL(eFizzBuzz::Null, FizzBuzz(i + 6<\/span>));\n        CPPUNIT_ASSERT_EQUAL(eFizzBuzz::Null, FizzBuzz(i + 7<\/span>));\n        CPPUNIT_ASSERT_EQUAL(eFizzBuzz::Null, FizzBuzz(i + 8<\/span>));\n        CPPUNIT_ASSERT_EQUAL(eFizzBuzz::Null, FizzBuzz(i + 9<\/span>));\n        CPPUNIT_ASSERT_EQUAL(eFizzBuzz::Null, FizzBuzz(i + 10<\/span>));\n        CPPUNIT_ASSERT_EQUAL(eFizzBuzz::Null, FizzBuzz(i + 11<\/span>));\n        CPPUNIT_ASSERT_EQUAL(eFizzBuzz::Null, FizzBuzz(i + 12<\/span>));\n        CPPUNIT_ASSERT_EQUAL(eFizzBuzz::Null, FizzBuzz(i + 13<\/span>));\n        CPPUNIT_ASSERT_EQUAL(eFizzBuzz::Null, FizzBuzz(i + 14<\/span>));\n    }\n}<\/code><\/pre>\n
Rerun:<\/p>\n
!!!FAILURES!!!\nTest Results:\nRun:  1   Failures: 1   Errors: 0\n\n\n1) test: FizzBuzzTest::test_fizzbuzz (F) line: 104 fizzbuzz.cc\nequality assertion failed\n- Expected: Null\n- Actual  : Fizz<\/code><\/pre>\n
Line 104:<\/p>\n
        CPPUNIT_ASSERT_EQUAL(eFizzBuzz::Null, FizzBuzz(i + 6<\/span>));<\/code><\/pre>\n
Another test case fault; 6 is divisible by 3. Similarly 9 and 12. Similarly 10 is divisible by 5. Our test case has listed them all as \u00e2\u20ac\u0153Null\u00e2\u20ac\u009d.<\/p>\n
    void<\/span> test_fizzbuzz() {\n        for<\/span>( int<\/span> i = 0<\/span>; i < 100<\/span>*15<\/span>; i += 15<\/span> ) {\n            CPPUNIT_ASSERT_EQUAL(eFizzBuzz::FizzBuzz, FizzBuzz(i + 0<\/span>));\n            CPPUNIT_ASSERT_EQUAL(eFizzBuzz::Null, FizzBuzz(i + 1<\/span>));\n            CPPUNIT_ASSERT_EQUAL(eFizzBuzz::Null, FizzBuzz(i + 2<\/span>));\n            CPPUNIT_ASSERT_EQUAL(eFizzBuzz::Fizz, FizzBuzz(i + 3<\/span>));\n            CPPUNIT_ASSERT_EQUAL(eFizzBuzz::Null, FizzBuzz(i + 4<\/span>));\n            CPPUNIT_ASSERT_EQUAL(eFizzBuzz::Buzz, FizzBuzz(i + 5<\/span>));\n            CPPUNIT_ASSERT_EQUAL(eFizzBuzz::Fizz, FizzBuzz(i + 6<\/span>));\n            CPPUNIT_ASSERT_EQUAL(eFizzBuzz::Null, FizzBuzz(i + 7<\/span>));\n            CPPUNIT_ASSERT_EQUAL(eFizzBuzz::Null, FizzBuzz(i + 8<\/span>));\n            CPPUNIT_ASSERT_EQUAL(eFizzBuzz::Fizz, FizzBuzz(i + 9<\/span>));\n            CPPUNIT_ASSERT_EQUAL(eFizzBuzz::Buzz, FizzBuzz(i + 10<\/span>));\n            CPPUNIT_ASSERT_EQUAL(eFizzBuzz::Null, FizzBuzz(i + 11<\/span>));\n            CPPUNIT_ASSERT_EQUAL(eFizzBuzz::Fizz, FizzBuzz(i + 12<\/span>));\n            CPPUNIT_ASSERT_EQUAL(eFizzBuzz::Null, FizzBuzz(i + 13<\/span>));\n            CPPUNIT_ASSERT_EQUAL(eFizzBuzz::Null, FizzBuzz(i + 14<\/span>));\n        }\n    }<\/code><\/pre>\n
This will give us zero errors finally. We can be pretty confident in our maths now. Or can we? What about the edge cases? We\u00e2\u20ac\u2122ve done zero, but what about int_max<\/code>? What about negative numbers? Remember when you\u00e2\u20ac\u2122re testing, you\u00e2\u20ac\u2122re trying to find faults, you should test for every circumstance \u00e2\u20ac\u201c overflow, underflow, off-by-one errors, sign errors. I\u00e2\u20ac\u2122ll leave those for you (or you can check out my cpp11<\/a> repository and look at the fizzbuzz<\/a> example). The limit test is interesting though because it shows the use of C++\u00e2\u20ac\u2122s numeric_limits<\/code> to check the boundary cases.<\/p>\n
    int<\/span> digits = numeric_limits<int<\/span>>::digits;\n    int<\/span> max = numeric_limits<int<\/span>>::max();\n    int<\/span> min = numeric_limits<int<\/span>>::min();\n    switch<\/span>( digits ) {\n        \/\/ max = (2^n-1) ; min = -(2^n)<\/span>\n        \/\/ All happen to be identically, Null<\/span>\n        case<\/span> 15<\/span>:\n        case<\/span> 23<\/span>:\n        case<\/span> 31<\/span>:\n        case<\/span> 63<\/span>:\n            CPPUNIT_ASSERT_EQUAL(eFizzBuzz::Null, FizzBuzz(min));\n            CPPUNIT_ASSERT_EQUAL(eFizzBuzz::Null, FizzBuzz(max));\n            break<\/span>;\n        default<\/span>:\n            CPPUNIT_ASSERT_EQUAL(0<\/span>, digits);\n            throw logic_error("unsupported architecture"<\/span>);\n    }<\/code><\/pre>\n
Are we done then? No. We\u00e2\u20ac\u2122ve used a facility in our main application without testing it.<\/p>\n
void<\/span> FizzBuzz() {\n    for<\/span>(int<\/span> i = 0<\/span>; i <= 100<\/span>; i++) {\n        auto<\/span> fb = FizzBuzz(i);\n        if<\/span>(fb == eFizzBuzz::Null) {\n            cout << i << endl;\n        } else<\/span> {\n            cout << fb << endl;\n        }\n    }\n}<\/code><\/pre>\n
Our operator<<<\/code> implementation. Testing it is easy though because we\u00e2\u20ac\u2122ve generalised it to work on all streams, we can output to a string instead of the terminal and have cppunit<\/code> check those strings.<\/p>\n
    void<\/span> test_fizzbuzz_operator() {\n        ostringstream null, fizz, buzz, fizzbuzz;\n        null << eFizzBuzz::Null;\n        CPPUNIT_ASSERT_EQUAL(string("Null"<\/span>), null.str());\n        fizz << eFizzBuzz::Fizz;\n        CPPUNIT_ASSERT_EQUAL(string("Fizz"<\/span>), fizz.str());\n        buzz << eFizzBuzz::Buzz;\n        CPPUNIT_ASSERT_EQUAL(string("Buzz"<\/span>), buzz.str());\n        fizzbuzz << eFizzBuzz::FizzBuzz;\n        CPPUNIT_ASSERT_EQUAL(string("Fizzbuzz"<\/span>), fizzbuzz.str());\n    }\n\n    \/\/ ...<\/span>\n\n    CPPUNIT_TEST_SUITE(FizzBuzzTest);\n    CPPUNIT_TEST(test_fizzbuzz_operator);\n    CPPUNIT_TEST(test_fizzbuzz);\n    CPPUNIT_TEST_SUITE_END();<\/code><\/pre>\n
Output:<\/p>\n
!!!FAILURES!!!\nTest Results:\nRun:  2   Failures: 1   Errors: 0\n\n\n1) test: FizzBuzzTest::test_fizzbuzz_operator (F) line: 107 fizzbuzz.cc\nequality assertion failed\n- Expected: Fizzbuzz\n- Actual  : FizzBuzz<\/code><\/pre>\n
Hopefully the fault in line 107 is obvious:<\/p>\n
    CPPUNIT_ASSERT_EQUAL(string("Fizzbuzz"<\/span>), fizzbuzz.str());<\/code><\/pre>\n
I\u00e2\u20ac\u2122ve left the \u00e2\u20ac\u0153buzz\u00e2\u20ac\u009d lowercase.<\/p>\n
With that fixed we\u00e2\u20ac\u2122re in a position to be confident about our FizzBuzz implementation. By using a unit test system we\u00e2\u20ac\u2122ve also forced ourselves to not only write a working FizzBuzz, but also a well designed one. You should notice that, strangely, we haven\u00e2\u20ac\u2122t actually tested the actual FizzBuzz()<\/code> function.<\/p>\n
As written, this isn\u00e2\u20ac\u2122t testable. I\u00e2\u20ac\u2122m not going to present that because it\u00e2\u20ac\u2122s just another, much larger, string comparison; after a change to make FizzBuzz()<\/code> able to output to a string; and we\u00e2\u20ac\u2122ve already seen how to do that, so it becomes a typing exercise.<\/p>\n
ostream &FizzBuzz(ostream &s, int<\/span> n)\n{\n    for<\/span>(int<\/span> i = 0<\/span>; i <= n; i++) {\n        auto<\/span> fb = FizzBuzz(i);\n        if<\/span>(fb == eFizzBuzz::Null) {\n            s << i << endl;\n        } else<\/span> {\n            s << fb << endl;\n        }\n    }\n    return<\/span> s;\n}<\/code><\/pre>\n","protected":false},"excerpt":{"rendered":"
Unit testing is the name we give to the idea of writing code that tests our application code automatically. Essentially, its job is to exercise each piece of your application in isolation, and ensure that any data dependent bugs you might introduce accidentally, never make it into production releases. Personally, I also find it makes\u2026 Read More »<\/a><\/span><\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":[],"categories":[1],"tags":[66,107,6,106],"_links":{"self":[{"href":"https:\/\/www.fussylogic.co.uk\/blog\/index.php?rest_route=\/wp\/v2\/posts\/1186"}],"collection":[{"href":"https:\/\/www.fussylogic.co.uk\/blog\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.fussylogic.co.uk\/blog\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.fussylogic.co.uk\/blog\/index.php?rest_route=\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/www.fussylogic.co.uk\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=1186"}],"version-history":[{"count":3,"href":"https:\/\/www.fussylogic.co.uk\/blog\/index.php?rest_route=\/wp\/v2\/posts\/1186\/revisions"}],"predecessor-version":[{"id":1189,"href":"https:\/\/www.fussylogic.co.uk\/blog\/index.php?rest_route=\/wp\/v2\/posts\/1186\/revisions\/1189"}],"wp:attachment":[{"href":"https:\/\/www.fussylogic.co.uk\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=1186"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.fussylogic.co.uk\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=1186"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.fussylogic.co.uk\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=1186"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}
This is certainly workable; and has the advantage of being very simple. However, I recently got pointed at cppunit<\/a> by a posting on stackoverflow, and I like the structure it imposes on tests. After a bit of reading and messing I got enough boilerplate code that I find I\u00e2\u20ac\u2122d rather use cppunit<\/code> for unit tests, over my simple method. It\u00e2\u20ac\u2122s got the advantage that I can create a single unit test executable covering all modules, or test individual modules as I wish. It\u00e2\u20ac\u2122s got some nice output formats and allows easy separation and isolation of individual tests.<\/p>\n