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

41–50 of 60 posts

Re: TDD: tastes better without the T?

#41

Post by thibaut_barrere »

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.

Exactly - and it applies to regressions caused by changes in the system (ie: change of platform, of version of the language, security patches etc), not only to changes to your code.

Re: TDD: tastes better without the T?

#42

Post by grandalf »

How many tests would be made obsolete with basic aspect oriented programming? Oddly this has not really caught on in the Ruby community, probably because testing requires less thought and people are paid to write test code so why not just relax and write boilerplate CYA code and get paid for it.

The 80/20 rule applies to testing, but most people test things like basic ActiveRecord finders, etc. Why? Because writing a test of something complex requires a lot of thinking which hurts a bit.

In most apps, there is a "money work flow", such as signing someone up, taking an order, etc. If that stops working it's a really big deal. To adequately test it you probably need integration tests, but most devs don't bother to write that test because it's a pain and it fails a lot during development.

I think TDD is a bit of a cop out that can lead to an insufficiently specified API. If all it takes to make the test pass is to handle a narrow case of inputs, then you should feel no additional confidence just because the test passes.

Ideally running a test suite can tell you that the code is safe to deploy... Some tests can also speed up writing other code by making it easy to think through a problem with sample data.

If you are writing filler tests, useless tests, etc. just stop and figure out what is actually important.

If your unit tests take longer than 60 seconds you are probably doing it wrong.

Re: TDD: tastes better without the T?

#43

Post by aidenn0 »

theBobMcCormick wrote: post #39

I can completely understand there being disagreement about how to test code, how much testing is enough, when to write test (test driven vs write tests later), etc. But what boggles my mind is we've got people in this very thread who, if I'm interpreting their comments correctly, are arguing against doing any testing at all! WTF? How, in any non-trivial codebase, are you going to prevent regression? Does anyone here…

I may be reading things wrong, but I think people are arguing against unit testing, which is the focus of TDD.

I hope people aren't arguing against integration testing. I agree with the original post that unit-testing can become onanistic fairly easily, but I think that that is a failure mode for just about any coding style (coding for the sake of coding vs testing for the sake of testing).

Re: TDD: tastes better without the T?

#44

Post by mcculley »

I'm working on a project right now where I inherited a large functioning system that has no unit tests. As I'm making changes I'm adding some unit tests to prevent regression.

While I agree with the article that test cases are often overdone, I think that skipping test case implementation only works for those that have done enough design and implementation and learned where it should be skipped (e.g., where the only reasonable test case would just duplicate the implementation).

An important thing about TDD is that one is forced early to design the interfaces between components in such a way as to make testing possible. The test cases are less important than that the code is testable.

Re: TDD: tastes better without the T?

#45

Post by acemv »

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 does not matter if the end result is the same. More reliable, robust and less buggy software.

It takes a pragmatic developer to evaluate methodologies and patterns, utilizing the concepts that suites the job. Ultimately, mindless use of patterns and methodologies will not solve the problem.

Re: TDD: tastes better without the T?

#46

Post by bitwize »

This revolution in software process actually comes to us from practices employed by a secret brotherhood of programmers who have been keeping them alive since the sixties at least.

These practices were called "hacking".

The Way of the Hacker is subtle indeed, yet obvious; and it is hence prone to being rediscovered from time to time by people outside the core discipline.

Re: TDD: tastes better without the T?

#47

Post by ivorjawa »

Kind of an interesting article. I'm not sure if I'd state it quite the way he has. The best way I've ever seen it stated is: "test what you don't fully understand".

Test what you believe is fragile, or know is fragile.

Improve that later if you can, but your test suite is your safety net for keeping the nonobvious bits running. It's not a religion.

Don't test every assignment, just as you don't comment every assignment.

Re: TDD: tastes better without the T?

#48

Post by blasdel »

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.

Re: TDD: tastes better without the T?

#49

Post by sbov »

I usually only write tests for more complex pieces of code. For simple code, tests look too much like a violation of DRY for my taste. I do realize that 'simple' can be subjective though.

Re: TDD: tastes better without the T?

#50

Post by gruseom »

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…

Just want to say that I've been thinking about REPL vis-à-vis unit testing for a few years now and my experience and conclusions match yours very closely. You've done a nice job of articulating them (here and in the root comment).
Post reply on HN