Tactical testing is the incorporation of testing code into the working source code, so it is WhiteBoxTesting made extreme. I have heard about DesignForTestability, and we all know that TheSourceCodeIsTheDesign, so it follows that we should code for testability. As that's clearly a low-level operation, I call it TacticalTesting.

''Is this going to become a PatternLanguage for testing?''

''It could one day become a PatternLanguage for WhiteBoxTesting, but I am not so sure how much I believe in WhiteBoxTesting, nor how much time I have to do it.''

The things you want to achieve from tactical testing are:

* test all the paths in the program
* test unusual boundary conditions
* test unusual data sets
* allow RegressionTesting to be done by people other than the developers, and preferably with an automated TestingFramework
* ''[please add more here]''

It seems to me that tactical testing has to be language specific.
The code is language specific (!) and that's what we're interested in
testing.
As testing Java programs is my current problem, I will write about the
ideas I have had for that.

These ideas are called:

* ReportBugsSilently
* KeepErrorInformation
* CallAndCheckResult
* ThrowYourOwnException
* CodeClassInvariants
* CheckOutputAutomatically
* FakeTheSideEffects

There is some disagreement about:
* SubclassToTest

Techniques that are not tactical testing include:

* GuruChecksOutput
* TestingByPokingAround
* BigBangTesting

Contributors: JohnFarrell

See also: CategoryTesting TacticalTestingFramework
----
CategoryTesting