SitePoint Sponsor

User Tag List

Results 1 to 5 of 5
  1. #1
    SitePoint Guru BerislavLopac's Avatar
    Join Date
    Sep 2004
    Location
    Zagreb, Croatia
    Posts
    830
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Question Looking for some TDD tips

    I'm preparing to start working on an OOP library (in PHP5), and I intend to make it completely using the test-first approach. So I'm interested in personal tips and experiences from people doing that regularly (although I have done some TDD before, I still have a tendency to code before I think ).

    My project is currently in a very early phase: I have basic concept, and have identified primary classes involved together with their collaborations, but have not yet specified concrete individual responsibilities. What is your approach? Do you specify detailed responsibilities (methods) and then write tests, or write tests and then specify methods? What about classes with many attributes -- is there a way to test for knowledge responsibilities as well as for behavioral ones?

    Any other suggestions, besides those in questions, will be extremely useful.

  2. #2
    Non-Member
    Join Date
    Jan 2003
    Posts
    5,748
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    although I have done some TDD before, I still have a tendency to code before I think
    I suffer (greatly) from this same terrible infliction, for the most part. It's a habit which I can't overcome, and knowing that Test Driven Development can and does help does not help on the mental level

    I like the idea of your thread, and I too will be looking at this thread with great interest, so thanks for starting it, but I'm at a loss as to what I can help you with, sorry.

  3. #3
    simple tester McGruff's Avatar
    Join Date
    Sep 2003
    Location
    Glasgow
    Posts
    1,690
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I sometimes suspect that there is more upfront design going on in TDD than is sometimes acknowledged and that this is done unconsciously by more experienced programmers who instinctively think in terms of application layers, small, lean classes, and design patterns to link them all together.

    I always start by thinking through an idea to a stage where I feel it's worth testing. The amount of time spent on that would vary - a couple of minutes for something simple to a couple of hours or more if, say, I was designing a whole system of co-operating classes. By this time I'll know roughly the interface I want, and what neighbouring classes the class I'm writing will need to interact with (they'll all be mocked and written later, in turn). Nothing has been cast in stone: the pre-test planning is just a sketch which stays flexible as I work through the tests. I suppose the more experience you have, the better these first guesses will be. All I'm trying to do is avoid the risk of having to dump a whole pile of "bad" code & accompanying tests. As long as I'm roughly on the right track, bad choices are likely to be solvable with a bit of refactoring.

    It may be that I don't understand TDD properly, of course.

    Testing tips: the usual one of writing small, lean classes which do just one thing. Be receptive to "smells" from classes which are hard to test. Changing them to make them easier to test usually leads to a better design.

    Finally, here's an interesting article from Fowler on mocks v stubs.

  4. #4
    SitePoint Addict
    Join Date
    May 2003
    Location
    Calgary, Alberta, Canada
    Posts
    275
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by BerislavLopac
    still have a tendency to code before I think
    I think most of us do. TDD is like Aesop's fable The Tortoise and the Hare. The Hare is the developer who code's before he thinks and jumps out to a big lead in the race, hits a bug and has to sit at the side of the road to fix his bug. The Tortoise in the developer who is slow and steady and never stops until the finish line. He write's his test first, see's the red bar, codes the simplest possible thing to get the green bar, refactors and repeats until done. The tortoise will win in all but the simplest projects (shortest races ).

    My style of writing code is a mix between test-driven design, feature-driven design and domain-driven design. My use of those terms may not be completely pedantic but Ill try to explain.

    First pick the most important feature you (or your client or target audience) needs done. Write out what the feature is in the way you would talk about it to your client and they would talk about it to you. You should be able to determine your class name and methods from the way the feature is written.

    If the feature is "Save a File to the Filesystem". Your class may be FileSystem or File and your method is Save.
    Next write your failing test. Write your class and method. Make sure test passes. Refactor. Choose the next most important feature. Repeat.

    The most important and difficult part is refactoring. Refactoring involves:
    - changing class names or method names to coinside with the language you and your client use.
    - Splitting classes up into smaller classes with more distict roles.
    - Moving methods between different classes.
    - *Removing duplication*

  5. #5
    SitePoint Wizard
    Join Date
    May 2003
    Location
    Berlin, Germany
    Posts
    1,829
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I have never posted much in the "advanced" php section. This is probably because I've never seen myself as a very "advanced" programmer and feel that I've very little to add to most of the discussions going on in this forum, althought more advanced aspects of programming starts to "grow on" me now. However I read most of the topics in this forum, and I think Sean does aswell.

    It is part of our "duty" to be a regular participant in the forums. This does not however mean that we, as a team, are able to be regulars in every part of our section. There will always be a forum(s) that does not have a staff member posting in it regularly.

    We were elected, not only based of our level of knowledge, but because of a overall impression. Some people can be extremely knowing about programming, but lack other qualities we're looking for. Others have everything else, but don't know enough about programming. It all comes down to finding the right balance. Of course beeing "top-notch" in all aspects would be the best.
    Ditto completely.


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
  •