|
|
|
|
|
|
by qu4z-2
4905 days ago
|
|
|
As I said, very little that can improve test quality. :) Good to brainstorm though. But in my experience, anything that breaks flow (like those languages that refuse to compile if there's unused code, even if you've just commented something out for debugging) is a bad idea. Often it's nicest just to write the code, then write the unit tests once you've got the core idea down, rather than having to alternate between them at high frequencies. |
|
|
Loosen the unit test restrictions to just require that edge cases for function preconditions are tested. For example, a precondition 'x>3' would require a test calling a function the function with x=4 and one with x=MAXINT (if x is an int) or with x=nextFloat(3) and one with x=MAXFLOAT (if x is a float)
Ideally, the language would require gets for all edge conditions, but doing that is impossible. Instead, specify something similar to what Java does for 'variables must be provably initialized before use' to find easily detectable (in some sense) edge cases.
Also, allow the IDE to run and debug unit test code before it complies with the rules.
Keep the rule 'never write an object file that can be used outside of the IDE until the code passes tests'.
I think I could find such restrictions useful, if I were writing pacemaker software or something similarly critical.
If you find that too restricting, also allow debugging non-unit tet code from the debugger.