3 ms·

There is no one class of errors unit tests could solve, that's all about human-powered magic. In contrast, static typing, static code analysis and some methods

by kushti 13y ago

There is no one class of errors unit tests could solve, that's all about human-powered magic. In contrast, static typing, static code analysis and some methods of model checking could eliminate many kinds of errors before program run. TDD is necessary for dynamic languages with weak types. In other cases unit tests are good to ensure some properties, but TDD is not the good tool at all.

brodo 13y ago
I can see how you don't really need unit tests when using statically typed languages, but they are still handy. TDD is not only about unit testing, it's also about integration testing and acceptance testing. In my experience, integration testing is a lot more valuable than unit testing because you may make certain assumptions about the libraries you use which are not true. With your own code that's less of a problem.
- kushti 13y ago
  TDD is test-centric development, i.e when you write test first then code. Unit tests are needed, other tests are needed too, the question is it worth to make testing the core of development process. From my practice, no
  - sirmarksalot 13y ago
    So there's a hard-core "always test first" fringe, but very few people are really advocating testing all your getters and setters. Heck, I think my code coverage is probably something like 1% (most of the code base is dumb construction of view models from CMS content), though I can't speak for other programmers. The practical approach is to test the complicated stuff, and design your code so that you can test it if you need to. This leads to better modularity and easier reusability across the board.
seanmcdirmid 13y ago
Basically, when you write your program in Haskell or, if you want to go all out, even a more powerful static type system/proof checker (COQ, Agda), you are thinking in terms of proofs, which influences your design also. Are designs by proof really that different from designs by test? Interesting question. Fundamental limitations in the various forms of static analysis means that TDD is often quicker to work with (agility) and often way more expressive. Completeness that proofs depend on when the design is being formed is also often very elusive, which is why Haskell isn't such a great rapid prototyping language while LISP is.

by kushti 13y ago

brodo 13y ago

I can see how you don't really need unit tests when using statically typed languages, but they are still handy. TDD is not only about unit testing, it's also about integration testing and acceptance testing. In my experience, integration testing is a lot more valuable than unit testing because you may make certain assumptions about the libraries you use which are not true. With your own code that's less of a problem.

kushti 13y ago
TDD is test-centric development, i.e when you write test first then code. Unit tests are needed, other tests are needed too, the question is it worth to make testing the core of development process. From my practice, no
- sirmarksalot 13y ago
  So there's a hard-core "always test first" fringe, but very few people are really advocating testing all your getters and setters. Heck, I think my code coverage is probably something like 1% (most of the code base is dumb construction of view models from CMS content), though I can't speak for other programmers. The practical approach is to test the complicated stuff, and design your code so that you can test it if you need to. This leads to better modularity and easier reusability across the board.

seanmcdirmid 13y ago

Basically, when you write your program in Haskell or, if you want to go all out, even a more powerful static type system/proof checker (COQ, Agda), you are thinking in terms of proofs, which influences your design also. Are designs by proof really that different from designs by test? Interesting question. Fundamental limitations in the various forms of static analysis means that TDD is often quicker to work with (agility) and often way more expressive. Completeness that proofs depend on when the design is being formed is also often very elusive, which is why Haskell isn't such a great rapid prototyping language while LISP is.