Anyone who works in corporate style commercial software (or at least good corporate style commercial software) will tell you they figured this out years ago.
Probably before even TDD made the rounds.
TDD: tastes better without the T?
11–20 of 60 posts
Re: TDD: tastes better without the T?
#12This is sort of the consensus I've come to on TDD: It's a great way to learn good habits. This is important, because we really have surprisingly few solid ways of teaching a new developer good habits, and anything that doesn't involve "an experienced developer watching over your code every second" but can be done by yourself is a very good thing.
But there comes a time when it's time to discard it. The entire system promotes incredibly local thinking, and when you are incapable of thinking at a higher level (or thinking correctly, anyhow), learning to get the local stuff correct is a great start. Once you get that down cold though, and start moving up to higher levels of organization, TDD can start to be a net negative. I tried it out about 8 years into my career, and mostly what it did for me was tell me to aggressively walk into local optima that I knew in advance were local optima, and, by golly, were local optima even with TDD. But I'd recommend it to anyone who hasn't got the basic, local level stuff down cold, as knowing that stuff really well is a prerequisite to getting the higher stuff correct, and rather a lot of developers get a long way into their career without knowing that stuff well.
Re: TDD: tastes better without the T?
#13This experience is emphasized even more if you work in a language with a REPL, like Clojure. The only value of tests, at that point, are to protect against regressions. The testing process with a REPL happens faster and more organically than writing unit tests, but it's less structured and harder to formalize. It's like comparing a structured debate to a conversation. What someone needs to do (and I'll do eventually)…
A good REPL is one thing I find it really hard to program without. In many situations, I find ad-hoc testing by typing expressions in to the REPL to see that the return what I expect (or sometimes more experimentally, to see what they return so as to better understand an API) preferable to formal unit testing.
It's the main thing I miss when programming in Haskell. GHCi doesn't quite measure up to Lisp (or Ruby, or Python) REPLs.
Re: TDD: tastes better without the T?
#14This experience is emphasized even more if you work in a language with a REPL, like Clojure. The only value of tests, at that point, are to protect against regressions. The testing process with a REPL happens faster and more organically than writing unit tests, but it's less structured and harder to formalize. It's like comparing a structured debate to a conversation. What someone needs to do (and I'll do eventually)…
"The only value of tests, at that point, are to protect against regressions."
Which is still extremely important.
Re: TDD: tastes better without the T?
#15The biggest problem I have with TDD, or unit testing specifically, is the contortions (interfaces, mocking, delegating construction and configuration, configuration files, library dependencies, etc.) one has to go through to invert dependencies in statically typed languages. If only higher order module systems (think: parameterizing modules by their module dependencies, a bit like generic types are parameterized by type) were more popular, then huge chunks of this work wouldn't be necessary.
Add in preconditions, postconditions, DbC etc. and you can let the language help you out a whole lot more.
Re: TDD: tastes better without the T?
#16This experience is emphasized even more if you work in a language with a REPL, like Clojure. The only value of tests, at that point, are to protect against regressions. The testing process with a REPL happens faster and more organically than writing unit tests, but it's less structured and harder to formalize. It's like comparing a structured debate to a conversation. What someone needs to do (and I'll do eventually)…
Python Doctests do most of what you want.
That would be truer if the shell generated the Doctests for you. And if it did, how great would that be? I suspect that this would be easier in a functional (or maybe prototype inheritance) language than a traditional inheritance one, because you work directly with the objects that should carry your tests. In python you would have to decide whether the tests go on the object itself (unlikely but possible) or somewhere up its inheritance chain.
Re: TDD: tastes better without the T?
#17This experience is emphasized even more if you work in a language with a REPL, like Clojure. The only value of tests, at that point, are to protect against regressions. The testing process with a REPL happens faster and more organically than writing unit tests, but it's less structured and harder to formalize. It's like comparing a structured debate to a conversation. What someone needs to do (and I'll do eventually)…
Python Doctests do most of what you want.
Wow, Python doctests are awesome:
http://docs.python.org/library/doctest.html
Just copy paste the REPL interaction into a doc string, and you're done. Apparently, it recognizes ">>>" as the REPL prompt, and the following line as the expected output. The equivalent for Clojure would be a neat addition.
Re: TDD: tastes better without the T?
#18This experience is emphasized even more if you work in a language with a REPL, like Clojure. The only value of tests, at that point, are to protect against regressions. The testing process with a REPL happens faster and more organically than writing unit tests, but it's less structured and harder to formalize. It's like comparing a structured debate to a conversation. What someone needs to do (and I'll do eventually)…
"The only value of tests, at that point, are to protect against regressions." Which is still extremely important.
Especially if you go back and refactor and/or add new functionality to the code.
Re: TDD: tastes better without the T?
#19Earlier quoted context omitted.
Python Doctests do most of what you want.
Wow, Python doctests are awesome: http://docs.python.org/library/doctest.html Just copy paste the REPL interaction into a doc string, and you're done. Apparently, it recognizes ">>>" as the REPL prompt, and the following line as the expected output. The equivalent for Clojure would be a neat addition.
It's a neat hack -- I think there's definitely a gap though, in that there could be a tool that does some smarter introspection of your history and the state of the REPL to generate a unit test. v1 would be quite rudimentary, but after many iterations this could be an almost magical tool.
The "code-as-data" homomorphic semantics of lisp would make building something like this quite interesting, as it would probably need to transform some of the code you've REPLled from statements into assertions, etc.
Re: TDD: tastes better without the T?
#20Anyone who works in corporate style commercial software (or at least good corporate style commercial software) will tell you they figured this out years ago. Probably before even TDD made the rounds.
I don't understand, why only corporate style commercial software (which I guess I don't know what it is too :p
I thought the ones expected to already have this figured out are the awesome programmers, with more experience, the 10x more productive ones (which I do NOT include myself into). But why create this sub-group of "corporate style commercial"?