TDD: tastes better without the T?
coderoom.wordpress.com
TDD: tastes better without the T?
1–10 of 60 posts
Re: TDD: tastes better without the T?
#2This 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) is implement a REPL enhancement that allows "test capture". Namely, if you have recently evaluated one or more expressions, execute a "capture" command that extracts the working environment (locals, globals), the previous statements you've run, and their evaluated results, and outputs one or more unit tests. For example, a session with clojure might look like this:
> (def x 1)
> (def y 2)
> (+ x y)
3
> capture!
-- Saved capture001.clj
(1 test passed, 0 tests failed.)
Where capture.clj contains a test similiar to:
(def x 1)
(def y 2)
(def expected-result 3)
(assert-equal (+ x y) expected-result)
Fuzzy, and I apologize as I don't know the clojure unit testing syntax, but you get the idea. Of course, this is a baseline case, you'd need more functionality such as allowing the user to specify which parts of the environment to capture, and what results to assert, but these should fall out naturally as the tool is dogfooded.
Re: TDD: tastes better without the T?
#3This is an interesting point. When one starts to become dogmatic about any kind of 'best practices' it can be difficult to see what benefit is actually gained from them. In any given situation, you should know when and when not to apply them. Clearly, testing accessor methods is a sure way to drive any programmer numb with tedium.
Re: TDD: tastes better without the T?
#4This 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)…
That is a great idea, and one I'm going to implement in my copious free time.
Re: TDD: tastes better without the T?
#5This 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.
Re: TDD: tastes better without the T?
#6This 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.
Ah ha. I knew I couldn't have been the first person to think of this, as it's a natural enhancement to the REPL to support TDD. I'm not a pythonista, hence my lack of exposure to it, thanks!
Re: TDD: tastes better without the T?
#7This is an interesting point. When one starts to become dogmatic about any kind of 'best practices' it can be difficult to see what benefit is actually gained from them. In any given situation, you should know when and when not to apply them. Clearly, testing accessor methods is a sure way to drive any programmer numb with tedium.
Perhaps that counts as an argument against accessor methods?
Re: TDD: tastes better without the T?
#8This is an interesting point. When one starts to become dogmatic about any kind of 'best practices' it can be difficult to see what benefit is actually gained from them. In any given situation, you should know when and when not to apply them. Clearly, testing accessor methods is a sure way to drive any programmer numb with tedium.
Perhaps that counts as an argument against accessor methods?
Yes! You can never have too many arguments against accessor methods...
Re: TDD: tastes better without the T?
#9This 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)…
[deleted]
Re: TDD: tastes better without the T?
#10This 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)…
Yet another comment on HN that's significantly more insightful than the original article...