The Artima Developer Community
Sponsored Link

Weblogs Forum
Is Test-First Development an Impediment to Creative Flow?

41 replies on 3 pages. Most recent reply: May 1, 2006 7:18 AM by piglet

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 41 replies on 3 pages [ « | 1 2 3 | » ]
Girts Kalnins

Posts: 23
Nickname: smejmoon
Registered: May, 2003

Re: Is Test-First Development an Impediment to Creative Flow? Posted: Jan 28, 2005 5:14 AM
Reply to this message Reply
Advertisement
For uniterrupted flow you write prototype or several of them. When you have done exploration, then start writing production code test-first.

Rick Kitts

Posts: 48
Nickname: rkitts
Registered: Jan, 2003

Re: Is Test-First Development an Impediment to Creative Flow? Posted: Jan 28, 2005 7:07 AM
Reply to this message Reply
No, I almost never write my tests first. Indeed I don't really subscribe to test-first. I prefer test-lots. So I'll normally write a bit of code and then write some tests once I've committed to an implementation.

That being said, I'm always thinking about how I'm going to test something.

Steve Tooke

Posts: 4
Nickname: stevetooke
Registered: Jan, 2005

Re: Is Test-First Development an Impediment to Creative Flow? Posted: Jan 28, 2005 7:49 AM
Reply to this message Reply
> How can you write new code and tests with less risk of
> introducing bugs than by refactoring an existing solution
> with tests already in place? ;-)

That's not quite what I was driving at. The hacked solution we're talking about DOES NOT have tests, which is what the whole discussion is about. So rather than refactoring that solution and adding tests to it, you throw the solution away entirely and use what you learnt to write the tests and the code to satisfy them.

Steve Tooke

Posts: 4
Nickname: stevetooke
Registered: Jan, 2005

Re: Is Test-First Development an Impediment to Creative Flow? Posted: Jan 28, 2005 7:53 AM
Reply to this message Reply
> That's not quite what I was driving at. The hacked
> solution we're talking about DOES NOT have tests, which is
> what the whole discussion is about. So rather than
> refactoring that solution and adding tests to it, you
> throw the solution away entirely and use what you learnt
> to write the tests and the code to satisfy them.

I'd like to add that I never feel as confident with tests that I have added to code compared to tests that I have written code pass. I'm never quite sure if the tests I've written are based on the problem, or the code.

David Vydra

Posts: 60
Nickname: dvydra
Registered: Feb, 2004

Re: Is Test-First Development an Impediment to Creative Flow? Posted: Jan 28, 2005 1:03 PM
Reply to this message Reply
Sure, let me give you a concrete example. One of my more successful projects in recent years was a java to c# translator. It allowed a large part of an enterprise application to be shipped on .NET without any changes to its java code. The most complex part of the project was figuring out what parts of java can be translated to be semantically equivalent. All this knowledge is represented in the tests. This was an XP project that involved close interaction with the customers. Given the test suite, one can probably outsource the code without much risk.

I acknowledge that there are other kinds of software where the tests will not guarantee a usable implementation.

-david
www.testdriven.com

> Can you give an example of a situation where the tests are
> more important than the code?

Adrian Howard

Posts: 11
Nickname: ajh
Registered: May, 2003

Re: Is Test-First Development an Impediment to Creative Flow? Posted: Jan 29, 2005 1:11 AM
Reply to this message Reply
Yes I do really write my tests first - and curiously enough my experience has been the complete opposite ;-)

I've found TDD has helped me get and stay in flow. Write a test. Make it pass. Refactor. Repeat. Each stage has enough difficulty to keep my interest. Goals are clear and unambiguous at each stage. Lots and lots of immediate feedback. Each stage seems focused on the present.

The other thing I like is that since I started using TDD I've found it far easier to get into flow. I don't have to expend a lot of time and effort getting the big picture into my head - all I need to do is think about writing the next test, or getting it to pass. Some people go as far as deliberately leaving a failing test when they break from coding so they will know immediately that their next task is to get a green bar when they come back.

People I've worked with doing TDD have had similar experiences.

If what you do works for you, go for it :-) That said my guess for why TDD isn't working well is that you're writing too much code between tests and not letting the tests drive the design. Just as an experiment try writing only just enough code to get a test to pass, even if you end up returning constants and such. Then write the next test to break your obviously bogus code.

I had similar issues with TDD when I first tried it. The way I "got" TDD was by working in smaller and smaller test/code/refactor cycles. Working this way has been a revelation - working code just seems to... well... flow :-)

Dan Perl

Posts: 28
Nickname: nanov
Registered: Sep, 2004

Re: Is Test-First Development an Impediment to Creative Flow? Posted: Jan 30, 2005 7:05 AM
Reply to this message Reply
I consider test-first development to be a bottom-up design technique. It starts with small concrete objects and works towards generalizations through refactoring. There have always been people who use only bottom-up design and people who use only top-down design. I believe though that both techniques are useful and that they should be used as a combination. I also believe it's best to start at the level where you understand the problem best. If the high level is clearer to you, then start with a top-down design. If the low level is clearer, start with a bottom-up design. But eventually you have to alternate the two techniques.

Implicitly, the same is valid for test-first development. I'd say that both test-first and code-first are useful in different situations and should be used alternatively. We all are different people and we may be more comfortable with one technique or the other, but both are useful and neither should be ignored.

Michael Feathers

Posts: 448
Nickname: mfeathers
Registered: Jul, 2003

Re: Is Test-First Development an Impediment to Creative Flow? Posted: Jan 30, 2005 3:30 PM
Reply to this message Reply
One time when I was a kid I looked over at my father when he was driving our new car. It was manual and our old one was automatic. "Dad," I said, "isn't it hard to think about what gear to go in next?" He said "No, it gets to the point where you doing think about it."

I think a lot of "flow" stuff is like that. When something becomes second nature your thinking acclimates to it and you start to approach things in those terms.

I do a lot of test first, and I do notice myself jumping out of it periodically when I get some design insight and just want to go that way. It used to be harder to go back to writing the test first, but it is easier now and I think it is because I've gotten used to "finding the terrain" again. When you "jump out" you have to figure out how approach the next test to "jump in". It's sort of a like a language. In the beginning, you grapple with the words, but later as it sinks it, you "find them there" more often.

BTW, I've heard that flying helicopters is hard. There are all sorts of counter-intuitive motions you have to make to control the things. But, I suspect that helicopter pilots find flow too.

Eric Armstrong

Posts: 207
Nickname: cooltools
Registered: Apr, 2003

Re: Is Test-First Development an Impediment to Creative Flow? Posted: Feb 1, 2005 5:16 PM
Reply to this message Reply
Nicely said! I like your main theme--that we design in larger chunks that we test, and that it's therefore more natural to solve the design problem, implement it, and then refactor and test as necessary to ensure the solution is correct.

That is without doubt the way I work. I love unit testing, but I could never bring myself to write tests first. I suspect it's great discipline, but I could never accustom myself to it. Your article gives me a clue as to why. (Thanks for the pointer to the book, as well. I've been interested in what fuels my creativity for long-time-now.

Eric Armstrong

Posts: 207
Nickname: cooltools
Registered: Apr, 2003

Re: Is Test-First Development an Impediment to Creative Flow? Posted: Feb 1, 2005 5:21 PM
Reply to this message Reply
> The most complex part of the project was
> figuring out what parts of java can be translated to be
> semantically equivalent. All this knowledge is represented
> in the tests.
>
That is an interesting approach, as well. It seems more like "testing as knowledge capture". It's a great way to write specifications for the code, specifications which can be inspected and verified by the customer, and which surface the questions you need to know to write software which is really equivalent. In other words, it helps to identify the corner cases that might otherwords lead to an inconsistent implementation.

It seems more like "test-driven waterfall design", in that you could write the complete suite of tests before implementing anything--as opposed to the more incremental approach that "test driven design" usually stands for. But it seems like a great way to solve that particular kind of problem.

Alan Thompson

Posts: 1
Nickname: catalan
Registered: Oct, 2003

Re: Is Test-First Development an Impediment to Creative Flow? Posted: Feb 1, 2005 5:40 PM
Reply to this message Reply
Hi Bill,

Actually, the way you described your coding is how I seem to always end up doing it, as well. I first code up the class as I feel it should be (which often includes refactoring during the initial writing stage as more functionality is added and a more complete comprehension of the problem/solution is achieved). Then, when it is compiling, I comb through each method looking for possible oversights. I add test points to a peer testing driver class to verify I've not missed anything (often this turns up overlooked items!). Depending on the specific task, the test writing/running phase can take 1x - 2x as long as writing the original class!

While testing is a vital part of building reliable s/w, one should be careful to not rely too heavily on it, since each test is like a measuring a single point of a continuous function. No matter how many test points you have, there are still an infinite number of untested points remaining. The tests are there to support your reasoning about the correctness of the code, but they cannot replace it. So, I tend to rely on the logical reasoning first, with tests as a backstop to (hopefully) catch any ommisions in my reasoning.

Just because your tests haven't discovered a problem in the code doesn't mean that one doesn't exist!

Thomas Guest

Posts: 236
Nickname: tag
Registered: Nov, 2004

Re: Is Test-First Development an Impediment to Creative Flow? Posted: Feb 2, 2005 1:48 AM
Reply to this message Reply
> I like to think of refactoring and testing as editing.
> When writing an article, most
> writers first create an outline, then write the content,
> typically in a few sittings,
> and without regard to mistakes, typos, sentence structure,
> etc. Only then does an
> author spend most of his time on editing, fine-tuning, and
> polishing the article.

I take your point, but I think this is a misleading analogy. One can publish an article with a severely flawed structure - if the content is strong enough, readers may not mind. And typically, the author of the article retains ownership and may chose to correct the structural flaws in a later revision.

I prefer to take an incremental approach to code development. It's possible to grow a system: interfaces, interfaces + stub implementations, full implementations. At each stage, code gets checked in; and at no stage is anything truly broken. The structure is in place early on. Unlike most articles, software is often developed by a team - this incremental approach is more team friendly.

Of course, prototyping is a great way to shape a design, but I still adopt the approach described above when prototyping.

One of the benefits of "test first" is that it helps you get the interfaces right early on.

I do revise and polish code, but again in an iterative fashion: I want my code checked in early, and I want any code I check in to have undergone at least some polishing.

Ged Byrne

Posts: 22
Nickname: gedb
Registered: Nov, 2003

Re: Is Test-First Development an Impediment to Creative Flow? Posted: Feb 2, 2005 2:20 AM
Reply to this message Reply
I think Bill Venner's comments in the latest newsletter are exactly applicable here, regarding scalability. Especially:

"As you hack together more and more pieces, eventually the whole
thing wants to fall over. You have to make extra efforts to prop it up
so it doesn't fall over, and that *slows* you down. By contrast, taking
the time to build a solid architecture up front slows you down
initially, but can help you move much faster later."

Later on, if you want to be able to refactor your code with the full confidence that your unit tests will catch any unwanted side effects. For that confidence, every feature much be covered by tests.

The easiest way to ensure this is the TDD cycle. No code is written until the test is finished and proven to fail. If this discipline is maintained, you know for sure that no features have been introduced without a corresponding test.

If 10 features were introducd, then all 10 features must be tested. They simply could not have been coded without the test.

If, on the other hand, you write all the code and then add the tests how can you be sure that you have covered all of the features introduced?

If you introduced 10 features, how can you know with certainty that all 10 features are being tested? What if you only covered 8 of them?

Vincent O'Sullivan

Posts: 724
Nickname: vincent
Registered: Nov, 2002

Re: Is Test-First Development an Impediment to Creative Flow? Posted: Feb 2, 2005 6:56 AM
Reply to this message Reply
> If 10 features were introducd, then all 10 features must
> be tested. They simply could not have been coded without
> the test.

Why not?

Ged Byrne

Posts: 22
Nickname: gedb
Registered: Nov, 2003

Re: Is Test-First Development an Impediment to Creative Flow? Posted: Feb 2, 2005 7:12 AM
Reply to this message Reply
"why not?"

Because no new features are coded until the after the test has
been written and proven to fail.

There is the possibility that a feature was introduced unintentionally, which is why you should write no more than the code than is absolutely necessary to make the test pass.

You also have the test cases to show the intent of the interface.

For example, a developer using a feature may notice that a list is returned in ascending date order. Is this something they can rely on? To find out they can check the Unit Tests.

Is there a test to ensure the list's order? If so, then it is an enforced element of the features contract.

If no test exists, the ordering is coincidental and cannot be relied upon.

There is alway the option of adding such a test, thus extending the features contract.

Flat View: This topic has 41 replies on 3 pages [ « | 1  2  3 | » ]
Topic: Is Test-First Development an Impediment to Creative Flow? Previous Topic   Next Topic Topic: Prefactoring and Refactoring

Sponsored Links



Google
  Web Artima.com   

Copyright © 1996-2019 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use