3 ms·

Not sure at all what you mean. Can you describe what "guiding design and describing the behavior of the subject" looks like from the unit test's perspective? H

by Aqueous 13y ago

Not sure at all what you mean. Can you describe what "guiding design and describing the behavior of the subject" looks like from the unit test's perspective? How else are we to specify the behavior of a function than to specify, for a given combination of typed parameters, what is the return value? As the article points out it is impossible to exhaust the space of all possible combinations - but nobody is trying to do that, so it is a straw man. For me, I test the branches that are likely to occur in a production setting, and any obvious edge cases that might occur, but infrequently.

jasonlotito 13y ago
> Can you describe what "guiding design and describing the behavior of the subject" looks like from the unit test's perspective? That's the first part of unit testing. You write a test that fails. By doing that, you are describing what the API should look like. The unit test guides the design of the interface, and how that object works. People do this, even if they aren't unit testing. You've done this if you've ever written some code calling a method, knowing that the method isn't there yet. But you stub it in, and then go write the method.
- Aqueous 13y ago
  Right. And that's what I, and most other people who unit test, do. The unit test says nothing about how the object is implemented though - that's your job. As far as the unit test is concerned, the function is a black box. The unit test isn't concerned with the details of the implementation. For testing side effects (like the function's effect on a database) you sometimes work outside the function's parameters and return values. But the point remains - you are looking at what behavior the function exhibits from outside it.
- the_af 13y ago
  Just a nitpick: that's TDD, not unit testing in general. When unit testing guides the design, it's usually called TDD. It's perfectly acceptable to write unit tests _after_ the production code, and to not have them guide the design.
  - jasonlotito 13y ago
    You are right, of course. And that's what I meant. I just equate unit testing and TDD together so often that I tend to (incorrectly) equate the two.

by Aqueous 13y ago

jasonlotito 13y ago

> Can you describe what "guiding design and describing the behavior of the subject" looks like from the unit test's perspective? That's the first part of unit testing. You write a test that fails. By doing that, you are describing what the API should look like. The unit test guides the design of the interface, and how that object works. People do this, even if they aren't unit testing. You've done this if you've ever written some code calling a method, knowing that the method isn't there yet. But you stub it in, and then go write the method.

Aqueous 13y ago
Right. And that's what I, and most other people who unit test, do. The unit test says nothing about how the object is implemented though - that's your job. As far as the unit test is concerned, the function is a black box. The unit test isn't concerned with the details of the implementation. For testing side effects (like the function's effect on a database) you sometimes work outside the function's parameters and return values. But the point remains - you are looking at what behavior the function exhibits from outside it.
the_af 13y ago
Just a nitpick: that's TDD, not unit testing in general. When unit testing guides the design, it's usually called TDD. It's perfectly acceptable to write unit tests _after_ the production code, and to not have them guide the design.
- jasonlotito 13y ago
  You are right, of course. And that's what I meant. I just equate unit testing and TDD together so often that I tend to (incorrectly) equate the two.