SitePoint Sponsor

User Tag List

Page 2 of 2 FirstFirst 12
Results 26 to 38 of 38
  1. #26
    SitePoint Wizard DougBTX's Avatar
    Join Date
    Nov 2001
    Location
    Bath, UK
    Posts
    2,498
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Do you see writing tests as designing the code you are writing the tests for?
    Hello World

  2. #27
    Non-Member
    Join Date
    Jan 2003
    Posts
    5,748
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Oddly enough, you're at the same time more focussed on details but less bogged down in the details.
    This I can understand, and oddly enough I'm kinda having trouble trying to put it into words myself now

    Trying to find a suitable quote from Test Driven Development (the book) to better explain it but I can't, so without sounding too far off I hope, here goes...

    When you write your tests, you are investing your time and effort to make sure that what you pass into the test it's self (the data structure), is what you expect to get back out.

    What you get back from it is either a pass or a fail, there is no middle ground. The good thing about unit testing is that you can change the data (the structure remains the same) and test again, knowing that the data you put in each time the test comes back with a pass (you hope ).

    How the data (and for that matter, the structure - which could be an object) is manipulated is a tell tale sign on how the tests were used to design the implementation no?

    Just my thoughts anyways

    Do you see writing tests as designing the code you are writing the tests for?
    In some ways, yes for a short answer.

  3. #28
    SitePoint Wizard DougBTX's Avatar
    Join Date
    Nov 2001
    Location
    Bath, UK
    Posts
    2,498
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    How about this: with testing, you are saying what you want the code to do, and how to do it.

    You test the "what" in the tests, and you code the "how" into the application.

    If the "how" changes (refactoring), you still know that it does the same "what", because you have tests for it. But if you want to change the "what", you've got to change two things. So the trick with testing is to know when the "what" ends and where the "how" begins, so that you are not continually re-writing tests.

    Is that closer to the mark?

    Douglas
    Hello World

  4. #29
    Non-Member
    Join Date
    Jan 2003
    Posts
    5,748
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Yer, it is actually. A lot closer than where I was going with it anyways

  5. #30
    simple tester McGruff's Avatar
    Join Date
    Sep 2003
    Location
    Glasgow
    Posts
    1,690
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by DougBTX
    Do you see writing tests as designing the code you are writing the tests for?
    Absolutely.

    If you start by writing a test first, you have to ask the question what exactly is it that a particular piece of code should or shouldn't do. For example, I once had some code which worked with hash input but not with numerical arrays. A testFooWithHashInput and testFooWithNumericalArrayInput might have avoided that. The discipline of testing does two things: by leading you to think more carefully about the code, you're more likely to spot issues early on - but if you don't, fine-grained tests ought to let you track down the problem more easily later. By thinking about requirements first and then little bits of code which satisfy these constraints, the tests are driving the implementation of a class at the method level. Small steps "write little test then write a little code" help you to focus. It feels more like a process of discovery: you're learning to think more carefully anout nuances and to manage them rather than being attacked by them when they go wrong.

    Conversely, tests can also allow you to be quite unfocussed at times. Wild guesses might just work if you get lucky which is nice. Saves taking half an hour to really think it through - the tests are thinking for you in a sense. If the test passes, it must be OK.

    Testing can also drive the broader design. That starts by not doing too much - one of the XP principles is to do just enough to satisfy the requirements and no more. Suppose you need to create something which sends a weekly email. That's what the tests will specify and as soon as they run green you stop. Just might help to stop you charging off to create some kind of full-blown calendar app; the "weekly event" logic may well be a subset of a larger calendar domain but that can wait for another day. Also see http://www.agilelectric.com/2005/05/...ge-bedfellows/ where the developer felt they ended up being punished for failing to go beyond the requirements - or maybe the requirements were inadequately stated to begin with?

    It's easier to test lean classes which do just one thing and which don't cut across application layers - here again testing helps to drive the design. This might be one of the reasons why testing is sometimes seen as a chore.

    With interaction-based testing and TDD, testing can be used explicitly as a design tool. As you start playing around with code to satsify a test for the primary class, you might discover responsibilities which don't really fit. These can be mocked out - you've just discovered a neighbouring object in the design. An interface for the mock can be written for the test, and the mock will be implemented later. Perhaps you'll discover more objects and so on and so on with the design rippling out from the starting point.

    Design, documentation, quality control, regression testing, continous integration... It's just incredibly important as a programming technique. It also ought to save time overall.

  6. #31
    simple tester McGruff's Avatar
    Join Date
    Sep 2003
    Location
    Glasgow
    Posts
    1,690
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by DougBTX
    So the trick with testing is to know when the "what" ends and where the "how" begins, so that you are not continually re-writing tests.
    Douglas
    Different styles of testing have an effect - see Mocks aren't Stubs.

    Interaction-based tests (using mocks) expose a small part of the implementation - the mock interface. This is exactly what you want when using testing as a design tool but it does mean that if you refactor a piece of code so that a mocked object drops out or new ones are created, tests also have to be changed to reflect that.

    State-based integration tests on the other hand provide a constant backbone against which to refactor. A state-based test doesn't care what other objects there are south in the design.

    I wouldn't like to say I've really mastered testing but what I tend to do is start of TDD-ing, creating lots of interaction based tests. Later I'll add integration tests and start replacing mocks with real classes. Still experimenting really.

  7. #32
    SitePoint Wizard
    Join Date
    Aug 2004
    Location
    California
    Posts
    1,672
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I went back to the SimpleTest site to see if the things I think would help people get into testing. Here are some things I notice:

    - Nowhere does it say obvious things like "it works well to put your tests in a directory named 'test' in your code directory then reference your files within tests by ../myfile.php" or "a common way to name your test files is ____" or "a common way to name your group test file is ___"

    - There does not seem to be any templates to download or with the source. Nor any helper scripts, though several people who test mentioned that they use them.

    - No example project is included with with tests that show how to layout the files, how organize unit and web tests, really how it all works together.

    My point in some of my comments above is that a side effect of being "test infected" is to loose site if the basics that are barriers to getting into testing. I'd bet that 90% of SimpleTest downloader stall on trivial stuff like the above before they ever get to the real challenge of understanding unit testing itself. Cheerleading is great and necessary, but seeing through the eyes of those new to testing is also necessary. This initial question was "When are people ready to learn to test?" I think this incorrectly assumes that all barriers to entry have been eliminated and it is only a matter of time.
    Christopher

  8. #33
    eschew sesquipedalians silver trophy sweatje's Avatar
    Join Date
    Jun 2003
    Location
    Iowa, USA
    Posts
    3,749
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    In my book I have an Appendix B - SimpletTest Testing Practices

    There were three testing related topics which did not fit well into the central topic of Design Patterns, but were important to the whole concept of unit testing. The three topics were: Test Case Scaffolding, Mock Object setup heuristics and WebTestCases.

    I think some of the issues you raised are addressed in these topics.
    Jason Sweat ZCE - jsweat_php@yahoo.com
    Book: PHP Patterns
    Good Stuff: SimpleTest PHPUnit FireFox ADOdb YUI
    Detestable (adjective): software that isn't testable.

  9. #34
    SitePoint Guru
    Join Date
    Oct 2001
    Posts
    656
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    - Nowhere does it say obvious things like "it works well to put your tests in a directory named 'test' in your code directory then reference your files within tests by ../myfile.php" or "a common way to name your test files is ____" or "a common way to name your group test file is ___"
    I don't see why it would 'work well' or 'work better' to name them like x.php or y.php.

    - No example project is included with with tests that show how to layout the files, how organize unit and web tests, really how it all works together.
    My guess is that lastcraft has left this out intentially. It would only be a limitation if Simpletest would require a fixed directory layout for the tests. People are free to set up the test directories the way they prefer.

    I don't believe in pre-chewing* everything to developers. If they're smart, which they must be since they're using Simpletest , they can probably figure it out themselves.

    Besides, I think Simpletest is one of the best documented PHP tools out there. Not just the API docs, but there are dozens of pages with real world code examples under test.

    I think you would agree with me if I say that I consider testing to be an advanced subject, not for your average PHP developer. It is a mental process to get to the 'stage' where you understand and appreciate or even see the necessity of unit testing.

    Problem is that unit testing seems to have become a buzzword and that attracts a certain class of people.

    * pre-chewing = translated from Dutch but I'm sure you can deduce its meaning.

  10. #35
    SitePoint Addict timvw's Avatar
    Join Date
    Jan 2005
    Location
    Belgium
    Posts
    354
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I don't find the generated API docs very usefull or informative (But i have that same feeling with the Java API docs too) I prefer the php documentation layout/grouping more..

    But i do like the examples at lastcraft's site..

  11. #36
    SitePoint Wizard
    Join Date
    Aug 2004
    Location
    California
    Posts
    1,672
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Captain Proton
    I don't see why it would 'work well' or 'work better' to name them like x.php or y.php.
    You miss my point. I wasn't saying to name your files a certain way. I was pointing out that obvious things like "put your tests in a 'test' directory are omitted. And that's a pretty standard practice. And notice how I carefully worded the statements so that they were not requirements, but just a guide for those starting out.

    Quote Originally Posted by Captain Proton
    My guess is that lastcraft has left this out intentially. It would only be a limitation if Simpletest would require a fixed directory layout for the tests. People are free to set up the test directories the way they prefer.

    I don't believe in pre-chewing* everything to developers. If they're smart, which they must be since they're using Simpletest , they can probably figure it out themselves.

    Besides, I think Simpletest is one of the best documented PHP tools out there. Not just the API docs, but there are dozens of pages with real world code examples under test.

    I think you would agree with me if I say that I consider testing to be an advanced subject, not for your average PHP developer. It is a mental process to get to the 'stage' where you understand and appreciate or even see the necessity of unit testing.

    Problem is that unit testing seems to have become a buzzword and that attracts a certain class of people.
    I agree that things like a fixed directory were purposely (and thankfully) left out. An I think the documentation is good for people like me. But again and again I hear that it is the peoples fault and there is really nothing to be done. I think I have spent some time giving real examples of little things that might be improved for beginners.

    This thread implies that there is a problem that not enough people are using unit testing tools, but there seems to be very little interest in any suggestions for improvements than those that involve changing the people.
    Christopher

  12. #37
    ********* Victim lastcraft's Avatar
    Join Date
    Apr 2003
    Location
    London
    Posts
    2,423
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    Hi...

    Whahay, feedback .

    Quote Originally Posted by arborint
    Nowhere does it say obvious things like "it works well to put your tests in a directory named 'test' in your code directory then reference your files within tests by ../myfile.php" or "a common way to name your test files is ____" or "a common way to name your group test file is ___"
    I actually wrote the tutorial part before I wrote most of the tool. Certainly the docs have been leading the code right up until last year. That kind of information was missing simply because I didn't have an answer then.

    Having a separate test directory does seem to be the most common approach (rather than a modular approach of groups of classes and tests). I think things have settled enough to at least have a discussion within the tutorial.

    Quote Originally Posted by arborint
    - There does not seem to be any templates to download or with the source. Nor any helper scripts, though several people who test mentioned that they use them.
    My feeling was that if there was a standard template then the set up code could just be automated. I went on a real purge to get rid of every possible line of code that didn't define a test. Every bit of boiler plate code if you like.

    I guess what's left is a bit shocking.

    Quote Originally Posted by arborint
    - No example project is included with with tests that show how to layout the files, how organize unit and web tests, really how it all works together.
    SimpleTest has tests, but I see what you mean. After 3.5 years of test driven I hopefully have a backlog of unconscious lessons learned. I don't yet know how to make it conscious.

    Anyone fancy a joint article for say, PHP magazine?

    Quote Originally Posted by arborint
    This initial question was "When are people ready to learn to test?" I think this incorrectly assumes that all barriers to entry have been eliminated and it is only a matter of time.
    The reason TDD is such a revelation to some is probably that by the time it's tried problems (debugging time) have been invisibly piling up, but test first didn't seem to be an answer. Certainly that was true in my case, although my hardware background made me predisposed to testing. Most developers who try fine grain testing have already sailed through their ideal point of exposure by the time they try it.

    There is also a motivation issue. You have to have been on a project that fell apart before project scale issues become of interest. If you have never had problems, or have unknowingly had problems, then you won't be ready for a solution.

    yours, Marcus
    Marcus Baker
    Testing: SimpleTest, Cgreen, Fakemail
    Other: Phemto dependency injector
    Books: PHP in Action, 97 things

  13. #38
    SitePoint Wizard
    Join Date
    Aug 2004
    Location
    California
    Posts
    1,672
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by lastcraft
    Whahay, feedback .
    Only you would find "feedback" in my whinging.
    Quote Originally Posted by lastcraft
    I guess what's left is a bit shocking.
    But beautiful to those who can appreciate it.
    Quote Originally Posted by lastcraft
    There is also a motivation issue. You have to have been on a project that fell apart before project scale issues become of interest. If you have never had problems, or have unknowingly had problems, then you won't be ready for a solution.
    I agree. However, I do think that "training wheels" help you do the the mechanical bits (steer and pedal) so you can gain confidence to be able to do the transcendent part (balance).
    Christopher


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
  •