Search icon CANCEL
Arrow left icon
Explore Products
Best Sellers
New Releases
Books
Videos
Audiobooks
Learning Hub
Conferences
Free Learning
Arrow right icon
Arrow up icon
GO TO TOP
Test-Driven Development with C++

You're reading from   Test-Driven Development with C++ A simple guide to writing bug-free Agile code

Arrow left icon
Product type Paperback
Published in Nov 2022
Publisher Packt
ISBN-13 9781803242002
Length 430 pages
Edition 1st Edition
Languages
Concepts
Arrow right icon
Author (1):
Arrow left icon
Abdul Wahid Tanner Abdul Wahid Tanner
Author Profile Icon Abdul Wahid Tanner
Abdul Wahid Tanner
Arrow right icon
View More author details
Toc

Table of Contents (21) Chapters Close

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

Supporting test setup and teardown

In order to support test setup and teardown, we only need to arrange for some code to run before a test begins and for some code to run after a test finishes. For the setup, we might be able to simply call a function near the beginning of the test. The setup doesn’t actually have to run before the test, as long as it runs before the test needs the setup results. What I mean is that the unit test library doesn’t really need to run the setup before a test begins. As long as the test itself runs the setup at the very beginning of the test, then we get the same overall result. This would be the simplest solution. It’s not really a new solution at all, though. A test can already call other functions.

The biggest problem I see with simply declaring a standalone function and calling it at the start of a test is that the intent can get lost. What I mean is that it’s up to the test author to make sure that a function called within...

lock icon The rest of the chapter is locked
Register for a free Packt account to unlock a world of extra content!
A free Packt account unlocks extra newsletters, articles, discounted offers, and much more. Start advancing your knowledge today.
Unlock this book and the full library FREE for 7 days
Get unlimited access to 7000+ expert-authored eBooks and videos courses covering every tech area you can think of
Renews at $19.99/month. Cancel anytime