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

21–30 of 60 posts

Re: TDD: tastes better without the T?

#21

Post by locopati »

An argument for tests. In a team (>3 developers) on a project that will have a lifespan (1+ years) where the cast of characters will change over time, tests provide continuity. The tests specify how functionality is meant to behave. Changes to code can be made with reduced worry about breaking existing functionality. When you're working in this kind of environment, you need to expand your horizon beyond your code and consider the needs of the team and the organization.

I wish I worked in language with a REPL that made it easier, but you work with what you have.

Re: TDD: tastes better without the T?

#22

Post by inerte »

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 think you would end up writing code in the REPL restricting what you would type because you know it'll become a test.

Then you wouldn't using a REPL for what a REPL can offer, but writing test code.

Unless it was really magical and would cover 100% of anything that someone could type in the REPL. If you were only using a subset of the REPL/languages features because you know your to-test-converter doesn't like some stuff, then you're writing the tests anyway.

Re: TDD: tastes better without the T?

#23

Post by ErrantX »

inerte wrote: post #20
ErrantX wrote: post #11

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.

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"?

Well all I meant was the kind of dull, grey, software packages that corporations pay thousands for.

As opposed to indie programmers or "cutting edge" commercial stuff - (i.e. Fogcreek, 37signals etc.) for whom things like TDD and agile tend to be big buzzwords.

(oops I didnt fully answer your question: and the reason I singled it out is because all the TDD/agile stuff just passes that industry by - they've been using SCM for years, write unit tests and, well, just "get the job done" (tm))

Re: TDD: tastes better without the T?

#24

Post by NickPollard »

eru wrote: post #7
spuz wrote: post #3

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

It's an argument against using accessors for the sake of using accessors.

It's important when learning any technique (and this goes not just for programming) to understand why that technique makes sense in this situation, which means that you can evaluate later situations on a case-by-case basis and decide whether or not that technique fits.

Too often people believe that a technique is good (Inheritance is good!) without fully appreciating why (Polymorphism). This means they start using it for other situations (code reuse) when it might make sense to do it another way (composition).

Re: TDD: tastes better without the T?

#25

Post by Tichy »

What frequently floors me is the complexity of the test frameworks and utilities. Look at an average Rails shop, and their list of test helpers goes on forever. Stuff like mockups, creating test data and so on.

I just hate learning frameworks.

My dogma is fun driven development. If something is not fun, you are probably doing it wrong. Creating mock objects and ever more abstract test frameworks is not fun to me (ymmv).

Re: TDD: tastes better without the T?

#26

Post by gfodor »

inerte wrote: post #22
gfodor wrote: post #19

Earlier quoted context omitted.

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 think you would end up writing code in the REPL restricting what you would type because you know it'll become a test. Then you wouldn't using a REPL for what a REPL can offer, but writing test code. Unless it was really magical and would cover 100% of anything that someone could type in the REPL. If you were only using a subset of the REPL/languages features because you know your to-test-converter doesn't like some…

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 behavior you want codified in a test, capture mode. These can in some cases be distinct processes (physically and mentally) and in other cases overlap so much as to look and feel like the same thing.

Re: TDD: tastes better without the T?

#27

Post by kowen »

One discovery that kind of blew my mind a few months back was approvals. I've seen the entire bowling game kata done with a single test.

It's a bit different to code against a failing approval when doing TDD; you still code in very small increments, but you don't necessarily get to green immediately. Slightly disturbing if you feel somewhat obsessive about seeing the green bar.

Locking down legacy code is beautiful. There is a screencast where the guys who developed approvals lock down a battleship game, generating about 8000 lines of output, not even glancing at them, and then refactoring the hell out of it.

http://approvaltests.sourceforge.net/

Re: TDD: tastes better without the T?

#28

Post by jimbokun »

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…

How much context do you need? An entire memory dump? The complete REPL history? If IO is involved, do you need to somehow guarantee the same files are available at test time with the same contents?

It seems to me the trick is to set sensible limits on the context of the current REPL state preserved at test time, in a way that works for most kinds of common unit tests. I believe this is the "magic" of which you speak.

Re: TDD: tastes better without the T?

#29

Post by bruceboughton »

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?

Re: TDD: tastes better without the T?

#30

Post by inerte »

gfodor wrote: post #26
inerte wrote: post #22

Earlier quoted context omitted.

I think you would end up writing code in the REPL restricting what you would type because you know it'll become a test. Then you wouldn't using a REPL for what a REPL can offer, but writing test code. Unless it was really magical and would cover 100% of anything that someone could type in the REPL. If you were only using a subset of the REPL/languages features because you know your to-test-converter doesn't like some…

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…

You're too lazy to open a file, type the unit tests and hitting CTRL+S but you're not lazy to open the REPL, type the unit tests and hit capture?

If you can't automate 100% of the REPL-into-test feature, if you need two mindsets/styles/etc, if you still need to "find the behaviour codified in a test", then you're just duplicating in the REPL the same workflow and results of writing the tests in a file. They need to overlap 100%.

Now, if they do, then it's awesome.

Post reply on HN