Frequently Asked Questions (FAQ)

1. Does "Test soon" work when exceptions are disabled?

   Yes, it should be able to detect this automatically. When exceptions are disabled, all checks must be directly in the test and not in a helper function.

   If you have exception support, "Test soon" should be able to take advantage of this automatically.

2. Why do you use macros (so much)?

   We believe that convenience is more important than purity. I have used testing frameworks without macros, so I know what I'm talking about. We believe that testing frameworks are one of the very few places where macros should be part of the public interface.

   Note that Equals etc. are macros, but you can use TESTSOON_Equals etc. instead and #undef the short names if you have conflicts. Depending on your naming convention, this will be more or less important.

3. But macros are evil!!!

   Indeed. There is even a Guru-of-the-Week article about the blessings of the Win32 "Sleep" macro et al. However, if, after serious consideration, macros are the only convenient alternative, we should and will use them.

   Convenience is especially important in testing, as you won't write tests if it is not convenient. That's our experience. Other than that, we tried hard to reduce risks. Especially dangerously named macros also have longer names so you can #undef the short version.

4. Where can I download "Test soon"?

   See the Sourceforge.NET download site or (for the most recent version) ViewMTN.

5. What does the name mean?

   Nice you ask. It's a promise. You will be able to test your code soon. Of course, no legal warranties or anything, but that's what we tried hard. Really hard - darkest magic we use inside.

6. Why is "Test soon" (core) organized as a single header?

   For ease of use. You can simply copy the header into your project directory. Or you can copy it to /usr/include. Whatever you prefer.

   Recently we decided that some optional functionality should be split out into different headers so this doctrine is not fully valid anymore.

   NEW: Some features are not part of the main header <testsoon.hpp> anymore. You can find them in <testsoon/*>.

7. Why don't you use a plain singleton instead of TEST_REGISTRY?

   Because it might not work. Depending on your compiler, the tests might build wihout any error message or warning but would not work. We considered three alternatives:

   1. Put the singleton into a .cpp file. The problem: "Test soon" could no longer be used as a single header file but would be a full-blown library. We discarded that quickly.
   2. Require the user to write a variable / function definition.
   3. Require the user to write a simple TEST_REGISTRY; somewhere.

   We chose the macro alternative because we considered it the simplest and most convenient.

8. Why is "Test soon" better?

   Because we are

   1. technologically advanced. We use bleeding edge techniques like preprocessor metaprogramming (yes) to ensure an optimal user experience.
   2. unbiased. There is no existing and well-known testing framework that we like so we just have to be unbiased. We won't just copy.
   3. hating compromise. We try to solve the full problem.

   As a consequence, you can write tests very quickly. You do not need to hassle with extremely complex template-subtemplate-specialization syntax. You do not need to care about test registration. There are generators, fixtures and other features to help you write your tests the way you imagine. And quite notably: You are not forced into a flat hierarchy. You can group as deep as you wish.

9. Why didn't you model the successful xUnit family of testing frameworks?

   Because it is not designed for C++. xUnit was first implemented for Smalltalk. This language does not share much with C++ - other than the superficial label "OOP". Nor does Smalltalk shared much with Java / .NET. Yet it was ported to Java and .NET and was made usable with the help of reflection and, lately, annotations. Still, the whole model has some restrictions that do make sense in the context of those languages but does not make any sense for C++. So we just imagined what would be best and implemented it.

10. "Test soon" lacks feature XYZ. It sucks!

    Help us implement it! Or maybe implement it even better than how "they" did. Maybe we'll even implement it without your help ;-).

11. Does anybody actually use "Test soon"?

    Yes.

    The main developers have been using it in their other projects lately. We even converted tests for a ~37000 line codebase (with low coverage, admittedly) from two different frameworks to "Test soon". We did not regret the step so far.

12. What are the requirements of "Test soon"?

    See Minimum requirements.

---