Strict Typing Isa Test

From UnitTestsReconsidered:: "StrictTypingIsaTest -- one that the compiler executes."

There are other ways to test.

In C++, the compiler is a big hunk of a UnitTests. Use it. It will help catch many really bad bugs. Moreover, good programming practices like SmartPointers and assert()ions eliminate bugs that would otherwise require testing. In fact, blackbox testing should be the last line of defence to eliminate bugs. Better coding practices are superior because they are more maintainable.

If your coding practices are really good--so good that your system remains simple enough to keep the bug count very low--then UnitTests may not be worth your time. It is possible. It just takes a lot of team maturity to pull it off.

Further, some domains aren't (easily) UnitTestable. Graphics programming, concurrent programming and close-to-the-metal programming are very hard to UnitTest.

: The most bug free application I've ever written (after six months, 24 discovered bugs, mostly in the quickly written GUI) was entirely graphical, concurrent and close-to-the-metal, and it was 200 000 lines of C++ written in seven weeks, so I know it's possible to test those systems without UnitTests. A lot of AcceptanceTests, a lot of TestingByPokingAround, a lot of good coding practices, and a lot of (informal) proofs of correctness. -- SunirShah

Anyone who can write a concurrent 200KLOC program in 49 days with that low a defect density is not being paid enough. It doesn't even matter what their salary is :-). I couldn't type 4000 lines in a day, even if I knew exactly what to type. And keeping it up for 49 straight days would give me a severe case of CarpalTunnelSyndrome.

I think I may agree with the conclusion, but the math seems off. 6 months is approximately 26 weeks. Working 5 days a week, this is 130 days. This gives slightly over 1500 lines per day, and slightly less than 200 lines per hour, assuming an 8 hour day. This all comes down to about 3.2 lines per minute. If I assume approximately 6 words per line (pretty verbose programming), then this can be done by someone who can type 20 words per minute. Of course, all compilation, testing, etc., has to be done after hours or on the weekends. I conclude the initial case is vastly overstated, and this whole section should be deleted.

I suspect that the critical part is ...a lot of (informal) proofs of correctness.

See:

DesignByContractAssertionsVsUnitTestsVsTypes, which says that strict typing is a way of testing.
And UnificationOfStaticTypesAndUnitTests, which explains which parts of UnitTests can be replaced by StaticTypeSafety.

Actually, strict typing isn't testing. Testing is a means of externally verifying the system. The type system of the compiler is internal to the system. In dynamic typed environments, you need to explicitly test what in other environments is given a priori. That's not to say that strict typing is good or bad, but it is to say that one should use the environment to its best advantage. The compiler is your friend. I'm amazed people fight ConstCorrectness. Also, it's also to say people who claim that testing is needed because in their environments it's useful aren't interesting unless they keep in mind your environment. Context is important.

Hmm: are UnitTests external to the system?

Some say StrictTypingIsaTest. Others say StrictTypingIsAnOptimization?. And we all know about premature optimization.

As a long time C/C++ programmer, I feel calling Strict Typing a "Test" is vastly overstating the case. Data typing is largely a product of the language you use and its use is best covered in a CodingStandard. Strict Typing is, at best, a trivial test. I find it does help, however, in the clarity of the code; put it in your coding standard. -- WayneMack

As another experienced C++ programmer, I really don't think this is overstated. Strict typing performs numerous testa that are executed when the compiler examines your code. It catches discrepancies between what you intended to write, and what you did write -- which is ultimately one of the main goals of testing. (Another goal is testing whether what you intended is what's really wanted!) Think about how often you get type errors of one sort or another when compiling new code, and think about what the code might have tried to do at run time if they hadn't been caught. The only question is whether the time spent designing new classes (types), which can be a large portion of your programming time in languages like C++, is offset by time saved in run-time debugging. -- DanMuller

with templates and strict typing you can write your own compile time tests (usually by only specialising the template correctly for cases that should work). these sort of compile time template checks are certainly proper tests -- JamesKeogh

See DoesUnitTestingMakeStaticTypingLessUseful

CategoryTesting