InfoQ

InfoQ

Presentation

My Bookmarks

Login or Register to enable bookmarks for unlimited time.

The content has been bookmarked!

There was an error bookmarking this content! Please retry.

Recorded at:
Recorded at

Steve Freeman On TDD: How Do We Know When We’re Done?

Presented by Steve Freeman on May 31, 2008 Length 00:54:28
Sections
Process & Practices,
Development
Topics
Agile ,
Agile Techniques ,
Unit Testing
Tags
QCon ,
Qcon London 2007 ,
TDD
The next QCon is in London March 5-9, Join us!
 

How would you like to view the presentation?

In case you are having issues watching this video, please follow these simple steps to help us investigate the issue:
1. Right click on the video player and select Copy log
2. Paste the copied information in an email to video-issue@infoq.com (clicking this link will fill in the default details in most email clients).
Note: in case your email client hasn't automatically picked up the email subject, please include in your email the URL of the video too.
3. Done.
We will investigate the issue and get back to you as soon as possible. Thanks for helping us improve our site!
Summary
Writing a test makes you clarify your ideas about what needs to be done, and making the test pass means that you know that you've added a little more functionality today. Having a comprehensive suite of tests gives you the confidence to get on with things because you can tell when you've broken the system, and tests that are difficult to write show you where you need to improve.

Bio
Steve was a pioneer of Agile software development in the UK, he has given training courses in Europe, America, and Asia. Previously, he worked in research labs, software houses, earned a PhD, and wrote shrink-wrap software for IBM. Steve also teaches in the Computer Science department at University College London.

About the conference
QCon is a conference that is organized by the community, for the community.The result is a high quality conference experience where a tremendous amount of attention and investment has gone into having the best content on the most important topics presented by the leaders in our community.QCon is designed with the technical depth and enterprise focus of interest to technical team leads, architects, and project managers.
Question at end about user stories and architecture by David Karr Posted
Re: Question at end about user stories and architecture by Romano Silva Posted
Re: Question at end about user stories and architecture by Kenrick Chien Posted
  1. Back to top

    Question at end about user stories and architecture

    by David Karr

    I listened to the entire presentation and through most of Steve's answer to the question about user stories and architecture, when I hit the Reply button, not realizing it would abort the rest of the presentation (I guess that comes from thinking Ajax :) ), so I'm not sure how he finished answering the question (there appears to be no way to fast-forward to the end (using the slider hangs the presentation)). However, it seems to me that that question addresses the crux of any reservations I have with TDD, and I believe many other people feel the same way.

    Sometimes I wish presentations about TDD would avoid spending the first 40 minutes talking about the usual trivial standalone simple class test case and focus on how you do this in real life.

    Steve may disagree with this, but the issue is that this is likely the perception of most non-TDDers, so it doesn't matter if you think I'm wrong, the issue is figuring out how to present TDD to convince people it can actually work. Frankly, testimonials don't do that for me.

  2. Back to top

    Re: Question at end about user stories and architecture

    by Romano Silva

    I think the whole evangelism over making the tests fail before and fix later kind of blinds people from having real answers from real problems. Agile came to fill in a hole we had in development in which the new tools and practices did not fit the waterfall approach.

    I think TDD is very good, but the relevance of the last question is of high importance. Bringing TDD to a company will not force the end of architecture and design. You can work out a great design beforehand and do the whole development based on that. That's how I view a perfect component based development methodology. A component design is a rough rock and the tests (with the component implementation) are the final polish touch. The design can be done focusing on testing scenarios (which I believe is a test driven design - I do not think that defining the design while coding the tests is the correct definition of test driven design). I would avoid, for example, designing singletons which cannot be reset in a tearDown() method because I know I will give developers a hard time to test, for example, failure scenarios, or loading different configurations (if that's the singleton's scope).

    Bottom line, I think it is not so important to see your tests failing first, but reaching a good coverage with well documented testing scenarios.
    The title of the presentation is 'How Do We Know When We’re Done?', but the focus was TDD for beginners. I was expecting to see something related to having a TDD team and how this team would progress on construction of the application during an iteration and have its 'Features Done' and approved using TDD.

    Tests are a great measure of quality, but 'How Do We Know When We’re Done?' is a question a PM would like answered at every status meeting. How the PM (which sometimes is not so technical) can take advantage of test results and test scenarios on his day to day? I think the best this presentation could get from that was showing the test names are actually use case scenarios.

    Thanks,
    Romano Silva
    EDS Brazil

  3. Back to top

    Re: Question at end about user stories and architecture

    by Kenrick Chien

    I think the whole evangelism over making the tests fail before and fix later kind of blinds people from having real answers from real problems.


    I have to disagree; at the macro level, often the tests are written according to specific requirements, and at the micro level, they are written to make sure classes/methods behave as expected.


    Bringing TDD to a company will not force the end of architecture and design. You can work out a great design beforehand and do the whole development based on that. That's how I view a perfect component based development methodology.


    This goes against agile practices and thinking; having a "big up-front design" (BUFD) usually, if not always, will require refactoring further down the road, unless one truly codes a perfect design the first-time around, and honestly, how often does that happen? Sure, it may be a good first attempt, but more often than not, it is not the ideal approach. After a while, you may see some code and think "Wow, I could move this method here, or this algorithm could be broken up like this, etc.?"

    Many times, coworkers will then reply "No, don't change it -- if it's not broke, don't try to fix it!"

    Like the quote from Beck and Gamma, shown in the presentation, TDD reduces fear and allows you to refactor mercilessly. Often, a clearer design becomes apparent only after coding the entire solution.



    A component design is a rough rock and the tests (with the component implementation) are the final polish touch. The design can be done focusing on testing scenarios (which I believe is a test driven design - I do not think that defining the design while coding the tests is the correct definition of test driven design).


    Adding the tests as a "final polish touch" would not be TDD -- wouldn't that be adding tests at the end? If so, most programmers would not add tests afterward, because it's too boring, or they would say there's no time, especially with pressure from management to just deliver the product already.

    Not only that, adding them as a "final" polish touch would not result in a testable design, in most, if not all cases. Writing the tests before you code ensures a testable design -- you are coding to your tests, not the other way around. How many times have you tried to write tests after the fact and simply given up? One class (let's call it "A") is often coupled to another class, called "B", and "B" will require access to a database, file system, or other external resource, making unit-testing "A" extremely difficult. On the other hand, if the tests were written before the design of "A", "A" would be easy to test because the tests are already in place! :)


    Bottom line, I think it is not so important to see your tests failing first, but reaching a good coverage with well documented testing scenarios.


    I think having failing tests helps design -- the reason is that the code is not in place yet, but your expectations of the code are already "documented", in a sense, by your assertions in the code. The failing part comes from having an empty, or non-existent method that doesn't do what your assertions state. Until they are coded correctly, your tests remain "red". Also, coverage usually happens at the same time you are writing your tests and code. With tools such as Clover and EclEmma, you get constant feedback that your tests are covering all code paths. The tests themselves serve as great documentation to show typical usage of code, and that your code handles a variety of inputs (boundary conditions), and errors/exceptions.

Educational Content

Collaboration: At the Extremities of Extreme

Jason Ayers share the observations he made watching a team of developers collaborating in real time on the same code base, pushing XP, pair programming and continuous integration to their extremes.

Yesod Web Framework

Michael Snoyman presents Yesod, a web framework written in Haskell and containing a web server, templating, ORM, libraries (templating, gravatar, etc.).

Transactions without Transactions

Richard Kreuter and Kyle Banker on how to avoid classical RDBMS transactional systems by using compensation mechanisms, transactional messaging or transactional procedures.

Attila Szegedi on JVM and GC Performance Tuning at Twitter

Attila Szegedi talks about performance tuning Java and Scala programs at Twitter: how to approach GC problems, the importance of asynchronous I/O, when to use MySQL/Cassandra/Redis, and much more.

10 tips on how to prevent business value risk

One category of risk that project teams need to ensure they address is business value failure – delivering a product that fails to provide value for the business investor.

Interview: Software Systems Architecture: Working With Stakeholders Using Viewpoints and Perspectives

InfoQ spoke to the authors of Software Systems Architecture on a couple of new topics, the System Context viewpoint and Agile, which have been added to the second edition.

Beauty Is in the Eye of the Beholder

Alex Papadimoulis discusses ugly code, where it comes from, how to avoid it, and how to get rid of it.

Architecting Visa for Massive Scale and Continuous Innovation

John Davies examines Visa’s architecture and shows how enterprises have architected complex integrations incorporating Hadoop, memcached, Ruby on Rails, and others to deliver innovative solutions.