On Mon, Dec 04, 2000 at 10:44:38AM -0800, Michel Pelletier wrote:
I have some suggestions for the outline:
Thank you very much for your input!
In the first section, remove "where does it come from" if the section involves the history of unit testing. I'd say the history lesson is out of scope. ;)
I would add a section in the beginning "Why do you want to use it".
The first section is the advocacy section; it will begin with "if you already do unit tests, you may want to skip this section". I'm not sure if the history lesson is out of scope, but "Why do you want to use it" is probably better.
What does "refactor mercilessly!" mean?
I'll explain that one of the benefits of unit testing extensively is that you can modify your code without fear (you'll know when it breaks). This section is more advocacy than technical.
Next section...
"Importing ZUnit" requires a whole section? I suggest axing it.
Hmm. Yes.
I would add an "example" section before moving into fitting it into Zope...
No, you can't do a lot without interfacing with Zope. I'd add an example *after* interfacing with Zope. Or both, perhaps. Maybe one example in the end of each subsection, so we don't need any subsection titled "example".
What are "Fixtures"?
A method where you make many tests in a single TestCase class. You setup a situation (the "fixture") in a method named "setup", then you do the tests, then you clean up in a method named "teardown". In the HiperDom tests, for example, I use a Fixture to do most of the tests, because I initialize the Template object in setup.
What is the "persistence problem"? If it is a bug that should be fixed in Zope then it probably shouldn't go in the documentation, if it is something the reader shouldn't do, then it should probably go into "interfacing with the Zope environment". A wart doesn't justify adding a new section just to add a sub-section to document it. ;)
I don't consider this a bug in either Zope or ZUnit, it's just an "issue". When you use "keep the objects" so that ZUnit doesn't delete the temp objects, *and* you use Fixtures, you can get problems with duplicate Ids, because the user wants to keep one object for each test, and "setup" usually creates objects with a fixed name. So, you have to either not use a fixed name on "setup", or use a fixed name and rename it to something unique in "teardown". I allocated a subsection for this because just explaining the problem is already somewhat convoluted, as you see above ;-) in a printed book, I'd make it a sidebar or something, but... []s, |alo +---- -- Hack and Roll ( http://www.hackandroll.org ) The biggest site for whatever-it-is-that-we-are. http://zope.gf.com.br/lalo mailto:lalo@hackandroll.org pgp key: http://zope.gf.com.br/lalo/pessoal/pgp Brazil of Darkness (RPG) --- http://zope.gf.com.br/BroDar