SitePoint Sponsor

User Tag List

Page 3 of 3 FirstFirst 123
Results 51 to 58 of 58

Thread: TDD, I love you

  1. #51
    ALT.NET - because we need it silver trophybronze trophy dhtmlgod's Avatar
    Join Date
    Jul 2001
    Location
    Scotland
    Posts
    4,836
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    The best way I've found to bring Mangement is demonstrate the ROI. If you have decent defect tracking, keep tabs on how much yours go down once you start using TDD. Try and work out all the time saved and present if with real business value.

    This post has some good advice too: http://codebetter.com/blogs/jean-pau...t-testing.aspx

  2. #52
    SitePoint Guru 33degrees's Avatar
    Join Date
    May 2005
    Posts
    707
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Chris Corbyn View Post
    You can write software with no bugs and which does what it should do but is still a heap of impossible to maintain and undocumented spaghetti. Assessing the quality of software requires more than a "well, it works so it must be good" evaluation.
    Agreed; I find that, for complex functionality, TDD can sometimes encourage a "poke at it until it works" attitude, where you make almost random changes in implementation until you get the behavior you're testing for. Then, inevitably, an edge case you didn't originally test for comes up, and you're back to poking your code trying to make the new tests pass.

    Of course, TDD doesn't have to be that way, as refactoring your code is an important part of the TDD process, but it can happen if you focus too much on the desired output and not enough on maintainable implementation.

  3. #53
    SitePoint Guru dagfinn's Avatar
    Join Date
    Jan 2004
    Location
    Oslo, Norway
    Posts
    894
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I mostly agree with Chris' answers to the 14 questions, so let me just add a few comments to some of them.
    Quote Originally Posted by phpimpact View Post
    1. BDD is an evolution of TDD.
    Quote Originally Posted by Chris Corbyn View Post
    1. True (it's still a form of TDD though)
    It's a form of TDD with different terminology and with tests chunked small enough to test a single behavior. Typically, that means more than one test method per method under test.
    Quote Originally Posted by phpimpact View Post
    2. In order to write code, first you have to write a test.
    Quote Originally Posted by Chris Corbyn View Post
    2. True for the most part. I don't write tests for simple accessors for example.
    The principle is, test anything that could fail. Accessors usually don't, but if they do for whatever reason, they should be tested and the tests should be written first.
    Quote Originally Posted by phpimpact View Post
    3. In TDD you cannot write code before writing a test, that includes a use cases analysis.
    Quote Originally Posted by Chris Corbyn View Post
    3. Mostly true. I'm not sure what your definition of "use case analysis" is though. I often open a blank file in the very early stages and sketch out how I'd like to use the API before I ever write it. Nothing final, just to get a rough feeling for it. This is NOT the same as writing code. It's the equivalent of grabbing a pad of paper and scribbling a few ideas down. My definition of "writing code" for the purposes of this discussion is "implementing the API".
    A use case is a requirements specification. It's not a sketch of the API. XP uses the simpler concept of user stories instead. Whether you use one or the other is not really relevant to the issue of TDD. Requirements specifications are not code. They resemble test code more than they resemble implementation code, so they can be replaced with acceptance tests if the user / customer is capable of reading and understanding them.
    Quote Originally Posted by phpimpact View Post
    4. The primary goal of a unit test is to design a system from the developer's perspective.
    Quote Originally Posted by Chris Corbyn View Post
    4. False. It's just as much about designing from a user's perspective. This is the whole emphasis - to focus your thoughts on the interface, not on the implementation. You're documenting behaviour upfront and only then are you implementing the code to provide that behaviour.
    I'd say the developer mostly, since the user doesn't see the internal APIs that are tested with unit tests. Acceptance tests are another matter.
    Quote Originally Posted by phpimpact View Post
    7. Once you have written some code, you cannot use the TDD technique.
    Quote Originally Posted by Chris Corbyn View Post
    7. True, provided you're referring to only that specific component. You can have selected parts of a system developed under TDD and other parts developed without. Just because you didn't use TDD on component X does not mean you cannot use it when you come to develop component Y.
    If you've written some code without tests, you can 1) add tests to it and then 2) continue to maintain it using TDD. There's probably some refactoring needed between 1) and 2).
    Dagfinn Reiersøl
    PHP in Action / Blog / Twitter
    "Making the impossible possible, the possible easy,
    and the easy elegant"
    -- Moshe Feldenkrais

  4. #54
    SitePoint Addict
    Join Date
    Sep 2006
    Posts
    232
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Thanks Dagfinn for the additional comments, one question though:

    Quote Originally Posted by dagfinn View Post
    A use case is a requirements specification. It's not a sketch of the API.
    Ok, my definition of Use Case Analysis is similar to the one in Wikipedia:

    Use Case Analysis: This step narrows down the class list into those classes that are capable of performing the behaviour needed to make the system function successfully. If no classes yet exist for a system, they must be created before this step can be completed.
    A use case analysis forces you to sketch the API. So that's why I was confused at the beginning. But I guess that the more TDD experience a developer has, the less he's going to analyse the system's behaviour before testing.

    So, is this correct?

    Traditional Development: User story > Use Case Analysis > Code > Unit Test
    TDD: User story > Unit Test > Code

  5. #55
    SitePoint Guru dagfinn's Avatar
    Join Date
    Jan 2004
    Location
    Oslo, Norway
    Posts
    894
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by phpimpact View Post
    Thanks Dagfinn for the additional comments, one question though:



    Ok, my definition of Use Case Analysis is similar to the one in Wikipedia:



    A use case analysis forces you to sketch the API. So that's why I was confused at the beginning. But I guess that the more TDD experience a developer has, the less he's going to analyse the system's behaviour before testing.

    So, is this correct?

    Traditional Development: User story > Use Case Analysis > Code > Unit Test
    TDD: User story > Unit Test > Code
    User stories are a specific technique that is used XP (extreme progamming) instead of use cases or other forms of requirements documents. The main difference is that user stories are much simpler. It's not a part of "traditional" development.

    I didn't read the Wikipedia article on use case analysis before, and I have to admit it confuses me. To me it seems to blur the distinction between user requirements and technical design. But I'm not a guru on use cases, so whether it's "correct" or not I can't say. Different experts may have slightly different terminology.

    EDIT: You're right. This is the definition of use case analysis. I wasn't familiar with the term. (More here: http://www.ibm.com/developerworks/ra...rary/5383.html) It doesn't blur the distinction, it describes the process from one to the other. I realize now that you're asking how you might use TDD in this rather elaborate process. As described, what it lacks from my point of view is primarily a clear realization of the limitations of up-front design. There's no harm in designing classes to the degree of detail proposed here (unless you spend too much time on it), but you have to be prepared to throw most of it away once you start getting real implementation code, because the code speaks and you need to listen. When develop the code using TDD, you discover things you were unable to realize when working on the design. The code you're referring to in use case analysis can then be seen as a design sketch rather than implementation code, and TDD presumably doesn't apply to it.
    Last edited by dagfinn; Apr 7, 2008 at 22:09.
    Dagfinn Reiersøl
    PHP in Action / Blog / Twitter
    "Making the impossible possible, the possible easy,
    and the easy elegant"
    -- Moshe Feldenkrais

  6. #56
    SitePoint Guru BerislavLopac's Avatar
    Join Date
    Sep 2004
    Location
    Zagreb, Croatia
    Posts
    830
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by McGruff View Post
    BDD is really just TDD repackaged with new labels.
    Actually, I'd rather say that TDD is really just BDD done quickly and with existing tools.

    Tests themselves are not the point of TDD; the point is that they test for certain behavior.

  7. #57
    SitePoint Guru dagfinn's Avatar
    Join Date
    Jan 2004
    Location
    Oslo, Norway
    Posts
    894
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by BerislavLopac View Post
    Actually, I'd rather say that TDD is really just BDD done quickly and with existing tools.

    Tests themselves are not the point of TDD; the point is that they test for certain behavior.
    BDD makes explicit that the relationship between test method and behavior should be one-to-one. One test method tests one behavior, instead of (typically) several behaviors of one method.
    Dagfinn Reiersøl
    PHP in Action / Blog / Twitter
    "Making the impossible possible, the possible easy,
    and the easy elegant"
    -- Moshe Feldenkrais

  8. #58
    SitePoint Addict
    Join Date
    Sep 2006
    Posts
    232
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Chris Corbyn View Post
    It's a good question and one I've never asked at work here. I wonder how they convinced Mark and Matt... something for me to bring up in tomorrow's dev meeting.
    Excellent, I'm definitively interested in knowing this, also the result obtained and how they managed to measure it.

    Quote Originally Posted by dagfinn
    The code you're referring to in use case analysis can then be seen as a design sketch rather than implementation code
    Yes, thanks, I wasn't familiar with the term design sketch.


Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •