Do you see writing tests as designing the code you are writing the tests for?
Do you see writing tests as designing the code you are writing the tests for?
This I can understand, and oddly enough I'm kinda having trouble trying to put it into words myself nowOddly enough, you're at the same time more focussed on details but less bogged down in the details.
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
In some ways, yes for a short answer.Do you see writing tests as designing the code you are writing the tests for?
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?
Yer, it is actually. A lot closer than where I was going with it anyways
Absolutely.Originally Posted by DougBTX
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.
Different styles of testing have an effect - see Mocks aren't Stubs.Originally Posted by DougBTX
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.
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.
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.
I don't see why it would 'work well' or 'work better' to name them like x.php or y.php.- 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 ___"
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.- 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.
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.
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..
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.Originally Posted by Captain Proton
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.Originally Posted by Captain Proton
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.
Whahay, feedback .
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.Originally Posted by arborint
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.
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.Originally Posted by arborint
I guess what's left is a bit shocking.
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.Originally Posted by arborint
Anyone fancy a joint article for say, PHP magazine?
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.Originally Posted by arborint
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.
Only you would find "feedback" in my whinging.Originally Posted by lastcraft
But beautiful to those who can appreciate it.Originally Posted by lastcraft
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).Originally Posted by lastcraft