Assumptions, imagine we are selling a software API:

  • a "system test" verifies that a system works by calling it's public interface e.g. assert(init()==true) or assert(MY_PI > 2 && MY_PI <= 10)
  • a set of "unit tests" verifies the public interface of implementation details (assuming OOP: all public methods and fields) does what is expected
  • an "integration test" is something in between and is not really important for the question.

What I wonder is what is the term/s for more localized whitebox tests :

  • private methods(and if You cluster that with "unit", what about lambdas?)
  • assert()*s peppered inside methods/functions.

* - referring to C++ asserts which compile to no operation in release code; not python asserts which are beautiful ifs

1 Answer 1


private methods(and if You cluster that with "unit", what about lambdas?)

I would not encourage tests targeting private methods or lambdas directly.

Unit tests are typically written as white-box tests. Even if you're following TDD patterns of red->green->refactor, the "refactor" step may include writing additional tests to provide coverage based on implementation details that further support building on or future refactoring.

Your unit tests at the method and class level should exercise private methods. Based on the implementation details of those private methods, you may choose to write additional test cases based on equivalence classes that exist within your private methods.

Writing tests that specifically target private methods are much more fragile when it comes to refactoring. A public interface should be much more stable than your private methods, meaning your tests are also more likely to be stable.

assert()*s peppered inside methods/functions.

These are not tests. Testing is when you execute a system under specified conditions. These are run-time checks of pre-conditions and post-conditions.

In languages like C++, you can remove assertions from deployed systems with a preprocessor while leaving them in when building for development or testing. However, I would consider the "test" to be the code that sets up the system's state and exercises it, not the assertions in the codebase.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.