Search icon CANCEL
Subscription
0
Cart icon
Your Cart (0 item)
Close icon
You have no products in your basket yet
Save more on your purchases now! discount-offer-chevron-icon
Savings automatically calculated. No voucher code required.
Arrow left icon
Explore Products
Best Sellers
New Releases
Books
Videos
Audiobooks
Learning Hub
Conferences
Free Learning
Arrow right icon
Test-Driven Development with C++
Test-Driven Development with C++

Test-Driven Development with C++: A simple guide to writing bug-free Agile code

eBook
$25.99 $37.99
Paperback
$46.99
Subscription
Free Trial
Renews at $19.99p/m

What do you get with Print?

Product feature icon Instant access to your digital eBook copy whilst your Print order is Shipped
Product feature icon Paperback book shipped to your preferred address
Product feature icon Download this book in EPUB and PDF formats
Product feature icon Access this title in our online reader with advanced features
Product feature icon DRM FREE - Read whenever, wherever and however you want
Product feature icon AI Assistant (beta) to help accelerate your learning
OR
Modal Close icon
Payment Processing...
tick Completed

Shipping Address

Billing Address

Shipping Methods
Table of content icon View table of contents Preview book icon Preview Book

Test-Driven Development with C++

Desired Test Declaration

If we’re going to have a test-driven development (TDD) process, we need tests. This chapter will explain what the tests will do, how we will write them, and how we will use them.

We’ll be starting from the very beginning and slowly building a full library to help manage and run tests, and we’ll be using the test library to help build itself. Initially, there will only be a single test. The following chapters will add more capabilities and grow the test library.

Starting with the end goal in mind, we’ll first think about what it will be like to create and use a test. Writing tests is a big part of TDD, so it makes sense to start thinking about testing even before we have the ability to create and run tests.

TDD is a process that will help you design better code and then make changes to your code without breaking parts that you’ve already verified to be working as expected. In order for this process to work, we need to be able to write tests. This chapter will explore what tests can do for us and how we can write them.

We’ll cover the following main topics in this chapter:

  • What do we want tests to do for us?
  • What should a test look like?
  • What information does a test need?
  • How can we use C++ to write tests?
  • How will the first test be used?

Technical requirements

All the code in this chapter uses standard C++, which builds on any modern C++ 17 or later compiler and standard library. Future chapters will require C++ 20 but for now, only C++ 17 is needed. The number refers to the year that the standard was approved and finalized, so C++ 17 was released in 2017 and C++ 20 was released in 2020. Each release adds new features and capabilities to the language.

The code we’ll be working with starts with an empty console project with a single source file called main.cpp.

If your development environment gives you a “Hello, world!” project when starting a new command line or console project, you can delete the contents of the main.cpp file because this chapter will start from the very beginning with an empty file.

You can find all the code for this chapter at the following GitHub repository: https://github.com/PacktPublishing/Test-Driven-Development-with-CPP.

What do we want tests to do for us?

Before we start learning about test-driven development, what it is, and what the process involves, let’s step back and think about what we want. Without knowing all the details about what a test is, let’s ask ourselves what our tests should look like.

I like to relate programming concepts to everyday experiences whenever possible. Maybe you have an idea to solve a problem that you have noticed and want to see whether your idea will work. If you wanted to test this idea before announcing it to the world, how would you do it?

You probably won’t be able to test everything to do with your idea at once. What would that even mean? There are probably small parts of your idea that you can think about initially. These should be easier to test and should help to clarify your idea and get you to think of other things to test.

So, let’s focus on simply testing small parts of the idea, whatever it is. You’d want to get everything set up and then start some actions or steps that should tell you whether each part works or not. Some of your tests might work well and some might cause you to rethink your idea. This is definitely better than jumping into the full idea without knowing whether it will work or not.

To put this into a real context, let’s say you have an idea to build a better broom. That’s a vague idea that’s hard to envision. However, let’s say that while sweeping the floor recently, you noticed your arms getting sore and thought that there had to be a better way. Thinking about the actual problem is a good way to turn a vague idea into something with a more solid meaning.

Now, you might start thinking about testing broom handles of different shapes, different grips, or different sweeping motions. These are the smaller parts of the idea that can be tested. You can take each grip or motion and turn it into a set of steps or actions that will test that part until you find one that works best.

Well, in programming, a set of steps can be a function. It doesn’t matter what that function does right now. We can think of each test as represented by a function. If you can call a function and it gives you the expected result, then you can say that the test passed. We’ll build on this idea throughout this book.

Now that we’ve decided to use a function for a test, what should it look like? After all, there are lots of ways to write a function.

What should a test look like?

It should be as simple to write a test as it is to declare and write a function, and we should be able to simplify things even further. A normal function can have whatever return type you want, a name, a set of parameters, and a body of code.

A function is also something that you write so that it can be called by other code. This code should know what the function does, what it returns, and what arguments need to be passed. We’ll keep things simple for our test functions and only worry about the name for now.

We want each test function to have its own name. Otherwise, how would we be able to keep track of all the various tests we’ll eventually be writing? As for the return type, we haven’t identified an actual need yet, so we’ll use void.

You’ll learn more about this process in Chapter 3, The TDD Process. When using TDD, don’t get ahead of yourself. Only do what you need to do at the time. As with the void return type, we’ll also not have any parameters.

It might seem too simple but this is a good start. So far, a test is nothing more than a function, which returns nothing and takes no parameters. It has a name to identify it and will include whatever code is needed to run the test.

Because we’re going to start using TDD to help design a simple testing library, our first test should ensure that we can create a test. This is a simple start, which defines a test function and calls it from main. All of this is in a single file called main.cpp:

#include <iostream>
void testCanBeCreated ()
{
    std::cout << "testCanBeCreated" << std::endl;
}
int main ()
{
    testCanBeCreated();
    return 0;
}

You might be thinking that this is not a test, it’s just a function that prints its own name, and you’d be right. We’re going to build it up from the very beginning in an agile manner using only what we have available. Right now, we don’t have a test library to use yet.

Still, this is starting to resemble what we eventually want. We want a test to be just like writing a function. If you build and run the project now, the output is as expected:

testCanBeCreated
Program ended with exit code: 0

This shows the output from running the program. It displays the name of the function. The text in the second line actually comes from my development tools and shows the program exit code. The exit code is the value returned from main.

This is a start but it can be improved. The next section will look at what information a test needs, such as its name.

What information does a test need?

The current test function doesn’t really know its name. We want the test to have a name so that it can be identified but does that name really need to be the name of the function? It would be better if the name was available as data so it could be displayed without hardcoding the name inside the test body.

Equally, the current test function doesn’t have any idea of success or failure. We purposefully ignored the test result until now, but let’s think about it. Is it enough for a test function to return the status? Maybe it needs a bool return type where true would mean success and false would mean the test failed.

That might be a bit too simplistic. Sure, it would be enough for now, but if a test fails, it might be good to know why. A bool return type won’t be enough later. Instead of designing the entire solution, we just need to figure out what to do that will meet the expected needs.

Since we already know that we need some data to hold the test name, what if we now add simple bool result data in the same place? This would let us keep the test function return type as void, and it leaves room for a more advanced solution later.

Let’s change the test function into a functor as follows so that we can add member data for the name and result. This new design moves away from using a simple function for a test. We need a class to hold the data for the name and result. A functor is a class that can be called like a function using operator(), as this code shows:

#include <iostream>
#include <string_view>
class Test
{
public:
    Test (std::string_view name)
    : mName(name), mResult(true)
    {}
    void operator () ()
    {
        std::cout << mName << std::endl;
    }
private:
    std::string mName;
    bool mResult;
};
Test test("testCanBeCreated");
int main ()
{
    test();
    return 0;
}

The biggest problem with this is that we no longer have a simple way to write a test as if it was a simple function. By providing operator (), or function call operator, we created a functor that will let us call the class as if it was a function from within the main function. However, it’s more code to write. It solves the problem of the test name, gives us a simple solution for the result, which can be expanded later, and also solves another problem that wasn’t obvious before.

When we called the test function in main before, we had to call it by the function name. That’s how functions are called in code, right? This new design eliminates that coupling by creating an instance of the Test functor called test. Now, main doesn’t care about the test name. It only refers to the instance of the functor. The only place in which the name of the test now appears in the code is when the functor instance is created.

We can fix the problem of all the extra code needed to write a test by using a macro. Macros are not needed in C++ as they used to be and some people might even think that they should be removed from the language entirely. They do have a couple of good uses left and wrapping up code into a macro is one of them.

We’ll eventually put the macro definition into a separate header file, which will become the test library. What we want to do is wrap up all the functor code in the macro but leave the implementation of the actual test function body to be written as if everything was a normal function.

First, we’ll make a simple change to move the implementation of the test function body outside of the class definition, like this. The function call operator is the method that needs to be moved outside:

class Test
{
public:
    Test (std::string_view name)
    : mName(name), mResult(true)
    {}
    void operator () ();
private:
    std::string mName;
    bool mResult;
};
Test test("testCanBeCreated");
void Test::operator () ()
{
    std::cout << mName << std::endl;
}

Then, the class definition, instance declaration, and first line of the function call operator can be turned into a macro. Compare the following code with the previous code to see how the Test class is turned into the TEST macro. By itself, this macro would not compile because it leaves the function call operator in an unfinished state. That’s exactly what we want because it lets the code use the macro like a function signature declaration and finish it up by providing the code inside the curly braces:

#define TEST class Test \
{ \
public: \
    Test (std::string_view name) \
    : mName(name), mResult(true) \
    {} \
    void operator () (); \
private: \
    std::string mName; \
    bool mResult; \
}; \
Test test("testCanBeCreated"); \
void Test::operator () ()
TEST
{
    std::cout << mName << std::endl;
}

Because the macro is defined over multiple lines, each line except the last needs to end with a backslash. The macro is a little more compact because the empty lines have been removed. This is a personal choice and you can leave the empty lines if you want. An empty line still needs the backslash though, which defeats the purpose of having an empty line.

The code uses the TEST macro with the unfinished function call operator just like a function definition, but then it completes the code by providing the curly braces and method implementation needed.

We’re making progress! It might be hard to see it because everything is in a single file. Let’s fix that by creating a new file called Test.h and moving the macro definition to the new file, like this:

#ifndef TEST_H
#define TEST_H
#include <string_view>
#define TEST class Test \
{ \
public: \
    Test (std::string_view name) \
    : mName(name), mResult(true) \
    {} \
    void operator () (); \
private: \
    std::string mName; \
    bool mResult; \
}; \
Test test("testCanBeCreated"); \
void Test::operator () ()
#endif // TEST_H

Now, we can go back to simpler code in main.cpp, like this next block of code shows. All we need to do is include Test.h and we can use the macro:

#include "Test.h"
#include <iostream>
TEST
{
    std::cout << mName << std::endl;
}
int main ()
{
    test();
    return 0;
}

We now have something that’s beginning to look like the simple function we started with, but there’s a lot of code hidden inside the TEST macro to make it seem simple.

In the next section, we’ll fix the need for main to call test() directly. The name of the functor, test, is a detail that should not be known outside of the macro, and we definitely shouldn’t need to call a test directly to run it, no matter what it’s called.

How can we use C++ to write tests?

Calling the test directly might not seem like a big problem right now because we only have one test. However, as more tests are added, the need to call each one from main will lead to problems. Do you really want to have to modify the main function every time you add or remove a test?

The C++ language doesn’t have a way to add extra custom information to a function or a class that could be used to identify all the tests. So, there is no way to look through all the code, find all the tests automatically, and run them.

One of the tenets of C++ is to avoid adding language features that you might not need, especially language features that affect your code without your awareness. Other languages might let you do other things, such as adding custom attributes, which you can use to identify tests. C++ defines standard attributes, which are intended to help the compiler optimize code execution or improve the compilation of your code. The standard C++ attributes are not something that we can use to identify tests and custom attributes would go against the tenet of unneeded features. I like this about C++, even if it means that we have to work a little harder to figure out which tests to run.

All we need to do is let each test identify itself. This is different from writing code that would try to find the tests. Finding the tests requires that they be marked in some way, such as using an attribute, so that they stand out and this isn’t possible in C++. Instead of finding them, we can use the constructor of each test functor so that they register themselves. The constructor for each test will add itself to the registry by pushing a pointer to itself onto a collection.

Once all the tests are registered through addition to a collection, we can go through the collection and run them all. We already simplified the tests so that they can all be run in the same way.

There’s just one complication that we need to be careful about. The test instances that are created in the TEST macro are global variables and can be spread out over many different source files. Right now, we have a single test declared in a single main.cpp source file. We’ll need to make sure that the collection that will eventually hold all the registered tests is set up and ready to hold the tests before we start trying to add tests to the collection. We’ll use a function to help coordinate the setup. This is the getTests function, shown in the following code. The way getTests works is not obvious and is described in more detail after the next code.

Now is also a good time to start thinking about a namespace to put the testing library into. We need a name for the namespace. I thought about what qualities stand out in this testing library. Especially when learning something like TDD, simplicity seems important, as is avoiding extra features that might not be needed. I came up with the word mere. I like the definition of mere: being nothing more nor better than. So, we’ll call the namespace MereTDD.

Here is the first part of the Test.h file with the new namespace and registration code added. We should also update the include guard to something more specific, such as MERETDD_TEST_H, like this:

#ifndef MERETDD_TEST_H
#define MERETDD_TEST_H
#include <string_view>
#include <vector>
namespace MereTDD
{
class TestInterface
{
public:
    virtual ~TestInterface () = default;
    virtual void run () = 0;
};
std::vector<TestInterface *> & getTests ()
{
    static std::vector<TestInterface *> tests;
    return tests;
}
} // namespace MereTDD

Inside the namespace, there is a new TestInterface class declared with a run method. I decided to move away from a functor and to this new design because when we need to actually run the test later, it looks more intuitive and understandable to have a method called run.

The collection of tests is stored in a vector of TestInterface pointers. This is a good place to use raw pointers because there is no ownership implied. The collection will not be responsible for deleting these pointers. The vector is declared as a static variable inside the getTests function. This is to make sure that the vector is properly initialized, even if it is first accessed from another .cpp source file compilation unit.

C++ language makes sure that global variables are initialized before main begins. That means we have code in the test instance constructors that get run before main begins. When we have multiple .cpp files later, making sure that the collection is initialized first becomes important. If the collection is a normal global variable that is accessed directly from another compilation unit, then it could be that the collection is not yet ready when the test tries to push itself onto the collection. Nevertheless, by going through the getTests function, we avoid the readiness issue because the compiler will make sure to initialize the static vector the first time that the function is called.

We need to scope references to classes and functions declared inside the namespace anytime they are used within the macro. Here is the last part of Test.h, with changes to the macro to use the namespace:

#define TEST \
class Test : public MereTDD::TestInterface \
{ \
public: \
    Test (std::string_view name) \
    : mName(name), mResult(true) \
    { \
        MereTDD::getTests().push_back(this); \
    } \
    void run () override; \
private: \
    std::string mName; \
    bool mResult; \
}; \
Test test("testCanBeCreated"); \
void Test::run ()
#endif // MERETDD_TEST_H

The Test constructor now registers itself by calling getTests and pushing back a pointer to itself to the vector it gets. It doesn’t matter which .cpp file is being compiled now. The collection of tests will be fully initialized once getTests returns the vector.

The TEST macro remains outside of the namespace because it doesn’t get compiled here. It only gets inserted into other code whenever the macro is used. That’s why inside the macro, it now needs to qualify TestInterface and the getTests call with the MereTDD namespace.

Inside main.cpp, the only change is how to call the test. We no longer refer to the test instance directly and now iterate through all the tests and call run for each one. This is the reason I decided to use a method called run instead of the function call operator:

int main ()
{
    for (auto * test: MereTDD::getTests())
    {
        test->run();
    }
    return 0;
}

We can simplify this even more. The code in main seems like it needs to know too much about how the tests are run. Let’s create a new function called runTests to hold the for loop. We might later need to enhance the for loop and this seems like it should be internal to the test library. Here is what main should look like now:

int main ()
{
    MereTDD::runTests();
    return 0;
}

We can enable this change by adding the runTests function to Test.h inside the namespace, like this:

namespace MereTDD
{
class TestInterface
{
public:
    virtual ~TestInterface () = default;
    virtual void run () = 0;
};
std::vector<TestInterface *> & getTests ()
{
    static std::vector<TestInterface *> tests;
    return tests;
}
void runTests ()
{
    for (auto * test: getTests())
    {
        test->run();
    }
}
} // namespace MereTDD

After all these changes, we have a simplified main function that just calls on the test library to run all the tests. It doesn’t know anything about which tests are run or how. Even though we still have a single test, we’re creating a solid design that will support multiple tests.

The next section explains how you will use tests by looking at the first test.

How will the first test be used?

So far, we have a single test that outputs its name when run, and this test is declared inside of main.cpp. This is not how you’ll want to declare your tests going forward. I’ve mentioned having multiple .cpp files with multiple tests in each one. We’re not ready for that yet but we can at least move the single test that we have into its own .cpp file.

The whole point of declaring multiple tests in multiple .cpp files is to help organize your tests. Group them into something meaningful. We’ll get to multiple tests later. For now, what is the purpose of our single test?

It is supposed to show that a test can be created. There may be other aspects of test creation that we’ll be interested in. So, it might make sense to create a .cpp file focused on test creation. Inside this .cpp file would be all the tests relating to different ways to create tests.

You can organize your tests however you want. If you have a project you are working on that has its own set of source files, it might make sense to group your tests around the source files. So, you would have a test .cpp file with many tests inside, which are all designed to test everything related to a .cpp file from your actual project. This would make sense if your project files were already organized well.

Or, you might take a more functional approach to organizing your tests. Since we only have a single header file called Test.h that we need to test, instead of also creating a single .cpp file to hold all the tests, let’s take a functional approach and split the tests based on their purpose.

Let’s add a new .cpp file to the project called Creation.cpp and move the single test that we have so far into the new file. At the same time, let’s think for a moment about how we will use the test library later on.

What we’re building is not really a library that gets compiled and linked into another project. It’s just a single header file called Test.h, which other projects can include. It’s still a library, just one that gets compiled alongside the other project.

We can even start treating the tests we have now this way. In the project structure, we have Test.h and main.cpp so far. The main.cpp file is similar to that of the test project that is intended to test the Test.h include file. Let’s reorganize the project structure so that both main.cpp and the new Creation.cpp files are in a folder called tests. These will form the basis for a testing executable that exercises all the tests needed to test Test.h. In other words, we’re turning the console project that we have into a test project designed to test the test library. The test library is not a separate project because it’s just a single header file that will be included as part of other projects.

Later on, in other projects of your own, you can do the same thing. You’ll have your primary project with all its source files. You’ll also have another test project in a subfolder called tests with its own main.cpp and all the test files. Your test project will include Test.h from the test library but it won’t be trying to test the test library as we’re doing here. It will instead be focused on testing your own project in the primary project folder. You’ll see how all this works once we get the test library to a suitable state so that it can be used to create a different project. We’ll be creating a logging library in Part 2, Logging Library. The logging library will have a subfolder called tests, as I just described.

Turning back to what we have now, let’s reorganize the overall project structure for the test library. You can create the tests folder and move main.cpp into it. Make sure to place the new Creation.cpp file into the tests folder. The project structure should look like this:

MereTDD project root folder
    Test.h
    tests folder
        main.cpp
        Creation.cpp

The main.cpp file can be simplified like this by removing the test and leaving only main:

#include "../Test.h"
int main ()
{
    MereTDD::runTests();
    return 0;
}

Now, the new Creation.cpp file only contains the single test we have so far, like so:

#include "../Test.h"
#include <iostream>
TEST
{
    std::cout << mName << std::endl;
}

However, building the project like so now gives a linker error, because we are including Test.h in both the main.cpp and the Creation.cpp compilation units. As a result, we have two methods that result in duplicate symbols. In order to remove the duplicate symbols, we need to declare both getTests and runTests to be inline, like this:

inline std::vector<TestInterface *> & getTests ()
{
    static std::vector<TestInterface *> tests;
    return tests;
}
inline void runTests ()
{
    for (auto * test: getTests())
    {
        test->run();
    }
}

Now, everything builds and runs again and we get the same result as before. The output displays the name of the single test we have so far:

testCanBeCreated
Program ended with exit code: 0

The output remains unchanged from before. We haven’t added any more tests or changed what the current test does. We have changed how the tests are registered and run, and we have reorganized the project structure.

Summary

This chapter has introduced the test library, which consists of a single header file called Test.h. It has also shown us how to create a test project, which is a console application that will be used to test the test library.

We have seen how this has evolved from a simple function into a test library that knows how to register and run tests. It’s not ready yet. We still have a way to go before the test library can be used in a TDD process to help you design and test your own projects.

By seeing how the test library evolves, you’ll come to understand how to use it in your own projects. In the next chapter, you’ll understand the challenges of adding multiple tests. There’s a reason why we only have a single test so far. Enabling multiple tests and reporting the results of the tests is what the next chapter will cover.

Left arrow icon Right arrow icon
Download code icon Download Code

Key benefits

  • Learn how a simple shift in focus will let you use tests to meet customer needs
  • Develop a testing library and a logging library that you can use in your own projects
  • Drive better code designs with effective tests that help new team members contribute faster

Description

Modern, standard C++ is all that is needed to create a small and practical testing framework that will improve the design of any project. This allows you to think about how the code will be used, which is the first step in designing intuitive interfaces. TDD is a modern balanced software development approach that helps to create maintainable applications, provide modularity in design, and write minimal code that drastically reduces defects. With the help of this book, you'll be able to continue adding value when designs need to change by ensuring that the changes don't break existing tests. In this book, you will use test-driven development (TDD) to gain practical skills by writing a simple testing framework and then using it to drive the design of a logging library. The book will help you enhance your software development skills with test cases. You'll understand how to design and implement test cases. The chapters will also show you how to utilize the TDD approach to be more productive in software development than attempting to code in large unstructured steps. By the end of this book, you'll have gained knowledge of TDD and testing and also built a working logging library with unique features not found in other libraries.

Who is this book for?

This book is for C++ developers already familiar with and using C++ for daily tasks who want to improve their skillset. You don’t need to be an expert but you should already have some knowledge of modern C++ and how to use templates to get the most out of this book.

What you will learn

  • Understand how to develop software using TDD
  • Keep the code for the system as error-free as possible
  • Refactor and redesign code confidently
  • Communicate the requirements and behaviors of the code with your team
  • Understand the differences between unit tests and integration tests
  • Use TDD to create a minimal viable testing framework
Estimated delivery fee Deliver to Malaysia

Standard delivery 10 - 13 business days

$8.95

Premium delivery 5 - 8 business days

$45.95
(Includes tracking information)

Product Details

Country selected
Publication date, Length, Edition, Language, ISBN-13
Publication date : Nov 18, 2022
Length: 430 pages
Edition : 1st
Language : English
ISBN-13 : 9781803242002
Languages :
Concepts :

What do you get with Print?

Product feature icon Instant access to your digital eBook copy whilst your Print order is Shipped
Product feature icon Paperback book shipped to your preferred address
Product feature icon Download this book in EPUB and PDF formats
Product feature icon Access this title in our online reader with advanced features
Product feature icon DRM FREE - Read whenever, wherever and however you want
Product feature icon AI Assistant (beta) to help accelerate your learning
OR
Modal Close icon
Payment Processing...
tick Completed

Shipping Address

Billing Address

Shipping Methods
Estimated delivery fee Deliver to Malaysia

Standard delivery 10 - 13 business days

$8.95

Premium delivery 5 - 8 business days

$45.95
(Includes tracking information)

Product Details

Publication date : Nov 18, 2022
Length: 430 pages
Edition : 1st
Language : English
ISBN-13 : 9781803242002
Languages :
Concepts :

Packt Subscriptions

See our plans and pricing
Modal Close icon
$19.99 billed monthly
Feature tick icon Unlimited access to Packt's library of 7,000+ practical books and videos
Feature tick icon Constantly refreshed with 50+ new titles a month
Feature tick icon Exclusive Early access to books as they're written
Feature tick icon Solve problems while you work with advanced search and reference features
Feature tick icon Offline reading on the mobile app
Feature tick icon Simple pricing, no contract
$199.99 billed annually
Feature tick icon Unlimited access to Packt's library of 7,000+ practical books and videos
Feature tick icon Constantly refreshed with 50+ new titles a month
Feature tick icon Exclusive Early access to books as they're written
Feature tick icon Solve problems while you work with advanced search and reference features
Feature tick icon Offline reading on the mobile app
Feature tick icon Choose a DRM-free eBook or Video every month to keep
Feature tick icon PLUS own as many other DRM-free eBooks or Videos as you like for just $5 each
Feature tick icon Exclusive print discounts
$279.99 billed in 18 months
Feature tick icon Unlimited access to Packt's library of 7,000+ practical books and videos
Feature tick icon Constantly refreshed with 50+ new titles a month
Feature tick icon Exclusive Early access to books as they're written
Feature tick icon Solve problems while you work with advanced search and reference features
Feature tick icon Offline reading on the mobile app
Feature tick icon Choose a DRM-free eBook or Video every month to keep
Feature tick icon PLUS own as many other DRM-free eBooks or Videos as you like for just $5 each
Feature tick icon Exclusive print discounts

Frequently bought together


Stars icon
Total $ 140.97
C++20 STL Cookbook
$46.99
Test-Driven Development with C++
$46.99
Template Metaprogramming with C++
$46.99
Total $ 140.97 Stars icon

Table of Contents

20 Chapters
Part 1: Testing MVP Chevron down icon Chevron up icon
Chapter 1: Desired Test Declaration Chevron down icon Chevron up icon
Chapter 2: Test Results Chevron down icon Chevron up icon
Chapter 3: The TDD Process Chevron down icon Chevron up icon
Chapter 4: Adding Tests to a Project Chevron down icon Chevron up icon
Chapter 5: Adding More Confirm Types Chevron down icon Chevron up icon
Chapter 6: Explore Improvements Early Chevron down icon Chevron up icon
Chapter 7: Test Setup and Teardown Chevron down icon Chevron up icon
Chapter 8: What Makes a Good Test? Chevron down icon Chevron up icon
Part 2: Using TDD to Create a Logging Library Chevron down icon Chevron up icon
Chapter 9: Using Tests Chevron down icon Chevron up icon
Chapter 10: The TDD Process in Depth Chevron down icon Chevron up icon
Chapter 11: Managing Dependencies Chevron down icon Chevron up icon
Part 3: Extending the TDD Library to Support the Growing Needs of the Logging Library Chevron down icon Chevron up icon
Chapter 12: Creating Better Test Confirmations Chevron down icon Chevron up icon
Chapter 13: How to Test Floating-Point and Custom Values Chevron down icon Chevron up icon
Chapter 14: How to Test Services Chevron down icon Chevron up icon
Chapter 15: How to Test With Multiple Threads Chevron down icon Chevron up icon
Index Chevron down icon Chevron up icon
Other Books You May Enjoy Chevron down icon Chevron up icon

Customer reviews

Rating distribution
Full star icon Full star icon Full star icon Full star icon Half star icon 4.5
(2 Ratings)
5 star 50%
4 star 50%
3 star 0%
2 star 0%
1 star 0%
Serban Stoenescu Jun 20, 2023
Full star icon Full star icon Full star icon Full star icon Full star icon 5
The book takes you from an empty project, it doesn't use any libraries, it makes the reader build one and use the TDD methodology on the library itself (and on other projects in other chapters). It's very interesting to see what all the test macros generate and what is happening behind the scenes. As a bonus, the reader has the opportunity to learn some modern C++ concepts that they might not know, which are also explained pretty well. I was honored to do the technical review part of this book.
Amazon Verified review Amazon
Howard Lee Harkness May 05, 2023
Full star icon Full star icon Full star icon Full star icon Empty star icon 4
I was personally disappointed in the approach the author used in the beginning of the book. The introductory material might make a good college text for "How to Build a Unit Test Framework," but only tangentially addressed how to write good, meaningful, unit tests. It's a bit like writing about how to write a compiler -- probably good to understand the general principals, but very few programmers will actually write (or even work on) a compiler. If not for the slow beginning, I probably would have given this book 5 stars instead of 4.It wasn't until chapter 8 (What Makes a Good Test?) that the author started to focus on how to write good unit tests. I consider chapter 8 to be the best chapter of the book, followed by chapters 12 (Creating Better Test Confirmations) and 13 (How to Test Floating-Point and Custom Values), where the author wrote about some theory behind constructing meaningful (and readable) unit tests, and a bit about the TDD process in general.The last third or so of the book was the most valuable (to me, anyway). I particularly like the treatment the author gave to unit testing of multi-threaded code.
Amazon Verified review Amazon
Get free access to Packt library with over 7500+ books and video courses for 7 days!
Start Free Trial

FAQs

What is the delivery time and cost of print book? Chevron down icon Chevron up icon

Shipping Details

USA:

'

Economy: Delivery to most addresses in the US within 10-15 business days

Premium: Trackable Delivery to most addresses in the US within 3-8 business days

UK:

Economy: Delivery to most addresses in the U.K. within 7-9 business days.
Shipments are not trackable

Premium: Trackable delivery to most addresses in the U.K. within 3-4 business days!
Add one extra business day for deliveries to Northern Ireland and Scottish Highlands and islands

EU:

Premium: Trackable delivery to most EU destinations within 4-9 business days.

Australia:

Economy: Can deliver to P. O. Boxes and private residences.
Trackable service with delivery to addresses in Australia only.
Delivery time ranges from 7-9 business days for VIC and 8-10 business days for Interstate metro
Delivery time is up to 15 business days for remote areas of WA, NT & QLD.

Premium: Delivery to addresses in Australia only
Trackable delivery to most P. O. Boxes and private residences in Australia within 4-5 days based on the distance to a destination following dispatch.

India:

Premium: Delivery to most Indian addresses within 5-6 business days

Rest of the World:

Premium: Countries in the American continent: Trackable delivery to most countries within 4-7 business days

Asia:

Premium: Delivery to most Asian addresses within 5-9 business days

Disclaimer:
All orders received before 5 PM U.K time would start printing from the next business day. So the estimated delivery times start from the next day as well. Orders received after 5 PM U.K time (in our internal systems) on a business day or anytime on the weekend will begin printing the second to next business day. For example, an order placed at 11 AM today will begin printing tomorrow, whereas an order placed at 9 PM tonight will begin printing the day after tomorrow.


Unfortunately, due to several restrictions, we are unable to ship to the following countries:

  1. Afghanistan
  2. American Samoa
  3. Belarus
  4. Brunei Darussalam
  5. Central African Republic
  6. The Democratic Republic of Congo
  7. Eritrea
  8. Guinea-bissau
  9. Iran
  10. Lebanon
  11. Libiya Arab Jamahriya
  12. Somalia
  13. Sudan
  14. Russian Federation
  15. Syrian Arab Republic
  16. Ukraine
  17. Venezuela
What is custom duty/charge? Chevron down icon Chevron up icon

Customs duty are charges levied on goods when they cross international borders. It is a tax that is imposed on imported goods. These duties are charged by special authorities and bodies created by local governments and are meant to protect local industries, economies, and businesses.

Do I have to pay customs charges for the print book order? Chevron down icon Chevron up icon

The orders shipped to the countries that are listed under EU27 will not bear custom charges. They are paid by Packt as part of the order.

List of EU27 countries: www.gov.uk/eu-eea:

A custom duty or localized taxes may be applicable on the shipment and would be charged by the recipient country outside of the EU27 which should be paid by the customer and these duties are not included in the shipping charges been charged on the order.

How do I know my custom duty charges? Chevron down icon Chevron up icon

The amount of duty payable varies greatly depending on the imported goods, the country of origin and several other factors like the total invoice amount or dimensions like weight, and other such criteria applicable in your country.

For example:

  • If you live in Mexico, and the declared value of your ordered items is over $ 50, for you to receive a package, you will have to pay additional import tax of 19% which will be $ 9.50 to the courier service.
  • Whereas if you live in Turkey, and the declared value of your ordered items is over € 22, for you to receive a package, you will have to pay additional import tax of 18% which will be € 3.96 to the courier service.
How can I cancel my order? Chevron down icon Chevron up icon

Cancellation Policy for Published Printed Books:

You can cancel any order within 1 hour of placing the order. Simply contact customercare@packt.com with your order details or payment transaction id. If your order has already started the shipment process, we will do our best to stop it. However, if it is already on the way to you then when you receive it, you can contact us at customercare@packt.com using the returns and refund process.

Please understand that Packt Publishing cannot provide refunds or cancel any order except for the cases described in our Return Policy (i.e. Packt Publishing agrees to replace your printed book because it arrives damaged or material defect in book), Packt Publishing will not accept returns.

What is your returns and refunds policy? Chevron down icon Chevron up icon

Return Policy:

We want you to be happy with your purchase from Packtpub.com. We will not hassle you with returning print books to us. If the print book you receive from us is incorrect, damaged, doesn't work or is unacceptably late, please contact Customer Relations Team on customercare@packt.com with the order number and issue details as explained below:

  1. If you ordered (eBook, Video or Print Book) incorrectly or accidentally, please contact Customer Relations Team on customercare@packt.com within one hour of placing the order and we will replace/refund you the item cost.
  2. Sadly, if your eBook or Video file is faulty or a fault occurs during the eBook or Video being made available to you, i.e. during download then you should contact Customer Relations Team within 14 days of purchase on customercare@packt.com who will be able to resolve this issue for you.
  3. You will have a choice of replacement or refund of the problem items.(damaged, defective or incorrect)
  4. Once Customer Care Team confirms that you will be refunded, you should receive the refund within 10 to 12 working days.
  5. If you are only requesting a refund of one book from a multiple order, then we will refund you the appropriate single item.
  6. Where the items were shipped under a free shipping offer, there will be no shipping costs to refund.

On the off chance your printed book arrives damaged, with book material defect, contact our Customer Relation Team on customercare@packt.com within 14 days of receipt of the book with appropriate evidence of damage and we will work with you to secure a replacement copy, if necessary. Please note that each printed book you order from us is individually made by Packt's professional book-printing partner which is on a print-on-demand basis.

What tax is charged? Chevron down icon Chevron up icon

Currently, no tax is charged on the purchase of any print book (subject to change based on the laws and regulations). A localized VAT fee is charged only to our European and UK customers on eBooks, Video and subscriptions that they buy. GST is charged to Indian customers for eBooks and video purchases.

What payment methods can I use? Chevron down icon Chevron up icon

You can pay with the following card types:

  1. Visa Debit
  2. Visa Credit
  3. MasterCard
  4. PayPal
What is the delivery time and cost of print books? Chevron down icon Chevron up icon

Shipping Details

USA:

'

Economy: Delivery to most addresses in the US within 10-15 business days

Premium: Trackable Delivery to most addresses in the US within 3-8 business days

UK:

Economy: Delivery to most addresses in the U.K. within 7-9 business days.
Shipments are not trackable

Premium: Trackable delivery to most addresses in the U.K. within 3-4 business days!
Add one extra business day for deliveries to Northern Ireland and Scottish Highlands and islands

EU:

Premium: Trackable delivery to most EU destinations within 4-9 business days.

Australia:

Economy: Can deliver to P. O. Boxes and private residences.
Trackable service with delivery to addresses in Australia only.
Delivery time ranges from 7-9 business days for VIC and 8-10 business days for Interstate metro
Delivery time is up to 15 business days for remote areas of WA, NT & QLD.

Premium: Delivery to addresses in Australia only
Trackable delivery to most P. O. Boxes and private residences in Australia within 4-5 days based on the distance to a destination following dispatch.

India:

Premium: Delivery to most Indian addresses within 5-6 business days

Rest of the World:

Premium: Countries in the American continent: Trackable delivery to most countries within 4-7 business days

Asia:

Premium: Delivery to most Asian addresses within 5-9 business days

Disclaimer:
All orders received before 5 PM U.K time would start printing from the next business day. So the estimated delivery times start from the next day as well. Orders received after 5 PM U.K time (in our internal systems) on a business day or anytime on the weekend will begin printing the second to next business day. For example, an order placed at 11 AM today will begin printing tomorrow, whereas an order placed at 9 PM tonight will begin printing the day after tomorrow.


Unfortunately, due to several restrictions, we are unable to ship to the following countries:

  1. Afghanistan
  2. American Samoa
  3. Belarus
  4. Brunei Darussalam
  5. Central African Republic
  6. The Democratic Republic of Congo
  7. Eritrea
  8. Guinea-bissau
  9. Iran
  10. Lebanon
  11. Libiya Arab Jamahriya
  12. Somalia
  13. Sudan
  14. Russian Federation
  15. Syrian Arab Republic
  16. Ukraine
  17. Venezuela