4 ms·

>> "For every part of my code change, if I break the code, will a test fail?" Since "breaking code" is super subjective, and generally speaking, trying to "cov

>> "For every part of my code change, if I break the code, will a test fail?" Since "breaking code" is super subjective, and generally speaking, trying to "cover everything" is a recipe for hell. Anyone able to expand on what the author meant by this?

brucephillips 9y ago
> since breaking code is super subjective. Only to the extent that your spec is incomplete.
jcrben 9y ago
Meaning: if I break the feature, will I know about it from a test failure? Basically, you put the customer first. Make sure your features are tested such that they can't fail without a failing test before writing lower-level tests. This is also the approach advocated by the popular book Growing Object-Oriented Software Guided by Tests.
atticusCr 9y ago
That's actually, IMHO, a good asset that comes out of a good test and code coverage. I would be worried if after adding new piece of code or modifying an existing code if there is not a test that tells me that something is broken due my code. Here is where testing becomes very helpful.
michalc 9y ago
Perhaps this part is not clear / well defined, but roughly, I meant that code coverage is (about) 100% for the lines added/changed, and some "reasonable" subset of possible breaking changes would be picked up by failing tests. What I had in mind specifically in the answer, was the case of changing "interfaces" between parts of code. For example, the case of changing a function's arguments, or how it uses them, but omitting to change a call site. Checking that the call site just calls the function would not be enough to produce a failing test, especially without type safety. The test would actually need to assert on what the function does, e.g. its return value for a pure function. Yes, I think trying to test against every single possible breaking change is not valuable.

brucephillips 9y ago

> since breaking code is super subjective. Only to the extent that your spec is incomplete.

jcrben 9y ago

Meaning: if I break the feature, will I know about it from a test failure? Basically, you put the customer first. Make sure your features are tested such that they can't fail without a failing test before writing lower-level tests. This is also the approach advocated by the popular book Growing Object-Oriented Software Guided by Tests.

atticusCr 9y ago

That's actually, IMHO, a good asset that comes out of a good test and code coverage. I would be worried if after adding new piece of code or modifying an existing code if there is not a test that tells me that something is broken due my code. Here is where testing becomes very helpful.

michalc 9y ago

Perhaps this part is not clear / well defined, but roughly, I meant that code coverage is (about) 100% for the lines added/changed, and some "reasonable" subset of possible breaking changes would be picked up by failing tests. What I had in mind specifically in the answer, was the case of changing "interfaces" between parts of code. For example, the case of changing a function's arguments, or how it uses them, but omitting to change a call site. Checking that the call site just calls the function would not be enough to produce a failing test, especially without type safety. The test would actually need to assert on what the function does, e.g. its return value for a pure function. Yes, I think trying to test against every single possible breaking change is not valuable.