4 ms·

where TDD and refactoring fall apart This too is what I find most fascinating: Up to a point refactoring is far easier without TDD, but after that point, it's

where TDD and refactoring fall apart This too is what I find most fascinating: Up to a point refactoring is far easier without TDD, but after that point, it's much harder without it. I know it's not popular, but I think aspect oriented programming may be a nice way to eliminate this conflict. One question for HN is: Why is it considered bad practice to worry about the range of valid inputs and outputs for a method? Wouldn't this basic consideration, combined with functional testing, offer a far greater degree of confidence in the system than hundreds of unit tests alone, and be far less brittle?

jamesbritt 16y ago
"Why is it considered bad practice to worry about the range of valid inputs and outputs for a method?" Is it? I don't think I've heard people complain about ensuring valid arguments and return values. But they do argue over what's the best|right|coolest way to handle it. "Wouldn't this basic consideration, combined with functional testing, offer a far greater degree of confidence in the system than hundreds of unit tests alone, and be far less brittle?" As would appropriate use of automatic type checking. Rather than having my method call explicit code to check that an argument is an integer between 0 and 100 (for example), I'd rather define the method signature such that the argument has to adhere to the behavior of type IntBetweenZeroAndOneHundred. Basically, move some unit tests or explicit method code for argument properties into a type. But, as the article suggests, this gain in cleaner code or a nicer abstraction may reduce the granularity, making it harder to change later.
- spitfire 16y ago
  Some languages have this already. Specifically safety critical languages like Ada. Ever so slowly the entire industry is moving towards what ada had in 1983. Beyond this you can use the spark annotations on top of ada to verify code does what it's expected to. Here's some Ada range examples type My_Int is range 1..100; type byte is mod 28; type Sin_Values is digits 10 range -1.0..1.0; Then you can query the object for its range: z'range; or see if it's even valid, useful for finding stray bits switched by cosmic rays - I'm serious here. if z'valid then dowhatever; else printwarning;

jamesbritt 16y ago

"Why is it considered bad practice to worry about the range of valid inputs and outputs for a method?" Is it? I don't think I've heard people complain about ensuring valid arguments and return values. But they do argue over what's the best|right|coolest way to handle it. "Wouldn't this basic consideration, combined with functional testing, offer a far greater degree of confidence in the system than hundreds of unit tests alone, and be far less brittle?" As would appropriate use of automatic type checking. Rather than having my method call explicit code to check that an argument is an integer between 0 and 100 (for example), I'd rather define the method signature such that the argument has to adhere to the behavior of type IntBetweenZeroAndOneHundred. Basically, move some unit tests or explicit method code for argument properties into a type. But, as the article suggests, this gain in cleaner code or a nicer abstraction may reduce the granularity, making it harder to change later.

spitfire 16y ago
Some languages have this already. Specifically safety critical languages like Ada. Ever so slowly the entire industry is moving towards what ada had in 1983. Beyond this you can use the spark annotations on top of ada to verify code does what it's expected to. Here's some Ada range examples type My_Int is range 1..100; type byte is mod 28; type Sin_Values is digits 10 range -1.0..1.0; Then you can query the object for its range: z'range; or see if it's even valid, useful for finding stray bits switched by cosmic rays - I'm serious here. if z'valid then dowhatever; else printwarning;