Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

TDD: tastes better without the T?

coderoom.wordpress.com

Post reply on HN
Print view View original

51–60 of 60 posts

Re: TDD: tastes better without the T?

#51

Post by inerte »

gfodor wrote: post #33
gfodor wrote: post #26

Earlier quoted context omitted.

I'm confused. This would be a REPL enhancement , meaning it would be something you use as needed. Currenly, using the clojure REPL to test things comes with a twinge of guilt, as it is not being captured for regression tests. (and I am too lazy to write unit tests separately) This would make it so that using the REPL would cycle between two "styles", ad-hoc experimentation and then, when you've found some repeatable…

Yes, yes I am. :) The reason being, that first, it's annoying to have to set up the boilerplate for the file. Second, it's annoying to have to convert what I just exercised in the REPL into a test. (Setup, tear down, asserts.) The reason TDD works and is fun is that you are using tests to learn and explore. It just so happens the artifact of that learning ends up living forever as a test. In a REPL, I'm doing that sa…

I don't know, I'm still not convinced. Guess it'll have to be one of those things that I might change opinions after trying (if someone ever comes up with an implementation).

Re: TDD: tastes better without the T?

#52

Post by silentbicycle »

bruceboughton wrote: post #29
barrkel wrote: post #15

The 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 t…

I'd be interested for you to expand on what you mean by "higher order module systems". Do you have any links?

The ML community usually calls them "functors".

For examples, a package which implements a data structure, say, a red-black tree. The module is parametric over the tree type, so you have module of type "(some record) rbtree". It customizes the module for those, at compile-time.

Or, a module that does a compiler's code generation, which takes another module which provides specification for the processor architecture.

Everything is typechecked, etc. at compile time. There's overlap with both the STL and Haskell's typeclasses, but in ML it's done as part of the module system.

Re: TDD: tastes better without the T?

#55

Post by rue »

Mc_Big_G wrote: post #34

I'm pretty sure I lost a $150k job opportunity for saying that TDD is a waste of time if your product hasn't been validated as a money maker. I don't regret saying it either. Fast forward a month and I begin working on a pre-profit project that is so bloated with tests and unnecessary complexity that it took me a few days to really figure out what the hell was going on with the code. When I first started reviewing th…

That is just bad design; it has nothing to do with tests.

Re: TDD: tastes better without the T?

#56

Post by Xurinos »

blasdel wrote: post #48
Mc_Big_G wrote: post #34

I'm pretty sure I lost a $150k job opportunity for saying that TDD is a waste of time if your product hasn't been validated as a money maker. I don't regret saying it either. Fast forward a month and I begin working on a pre-profit project that is so bloated with tests and unnecessary complexity that it took me a few days to really figure out what the hell was going on with the code. When I first started reviewing th…

I agree wholeheartedly about preemptive TDD: http://ravimohan.blogspot.com/2007/04/learning-from-sudoku-s... Almost nobody in the Rails community uses foreign key constraints with ActiveRecord. I chafed against it at first, but if you're drinking their validation koolaid, it wouldn't add value in most cases, since the validations can add stronger constraints with better exceptions.

I am not familiar with the validation koolaid (can you summarize it?), but from my experience, you want great constraints in your database because there may be more than one entry point to your database. If your software layers outside the database are your only entry point, then you might be able to do away with constraints...

But also in my experience with multiple developers working on changing the schema and adding new features that result in new data, we are often very glad the database has the constraints in order to keep people honest and not screw up the data during release transitions and even during development. If the software layers below that business logic do a super great job of handling the constraints, then this is not an issue.

Re: TDD: tastes better without the T?

#58

Post by jsankey »

jimbokun wrote: post #14
gfodor wrote: post #2

This 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.

In fact, this the key reason that you need to have automated tests. I don't know anyone that commits a new feature without trying it -- be it (conveniently) at a REPL or via some other UI. But the manual "trying it out" method, REPL or otherwise, has always suffered from the fact that it cannot be easily repeated, so old features eventually get broken, and nobody notices. This is why I automate my tests, because their value over time exceeds the extra cost to write them vs. trying it out.

I think this is an aspect that the original article fails to take into account. Eliding tests can feel very liberating, and it allows you to plow ahead adding new features faster. Particularly in small, or at least new, projects. But over time reality catches up, and the lack of tests becomes a burden. You start avoiding adding new features, and particularly improving existing code, out of fear of breaking something. And so you end up more constrained than if you had added the right balance of tests along the way.

Writing software that is maintainable, with staying power of years or decades, requires the sacrifice of some up-front productivity.

Re: TDD: tastes better without the T?

#59

Post by gruseom »

gfodor wrote: post #19
jimbokun wrote: post #17

Earlier quoted context omitted.

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 n…

I dunno. I think this idea occurs to everyone who understands unit testing and then encounters REPLs; it certainly occurred to me under those circumstances and I got excited about it for a while too. Over time, though, it has struck me as less and less obviously good. Though you're right about where the two approaches to programming overlap, and I agree with you that REPL > tests in those areas, there's also considerable territory where they don't overlap. I suspect that xor represents an impedance mismatch that makes "test capture" not as feasible as it seems at first.

I don't mean to pour cold water on the idea, though; if someone figures out a way of doing it that's useful I'd happily change my mind.

Re: TDD: tastes better without the T?

#60

Post by SapphireSun »

acemv wrote: post #45

I fully accepted TDD at first, but now only implement certain principles that have helped me develop better software. I am not the type to implement needless code just for the sake of it. However, many times, unit testing have saved me from countless hours of debugging and introducing new bugs. I will admit, I am one of those developers that write code first, then unit test second. That's just my style, and it really…

I can't judge because I do the same, but I think part of the reason you're supposed to write the tests first is so that you aren't influenced by what you already wrote. Ie you test what's correct rather than testing the implementation.
Post reply on HN