Re: [Zope-dev] ZUnit - feedback convocation
On Mon, Dec 04, 2000 at 02:56:26PM -0800, Michel Pelletier wrote: > On Mon, 4 Dec 2000, Lalo Martins wrote: > > > 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. > > Hmm... actually in that case you may want to axe both "why" and the history. I agree. At most, one paragraph about each could go in "What is Unit Testing". > > > 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. > > Ah, ok I like it. I wonder if "refactor" is the right word; it's very > specific and it sounds like any kind of changing can be done. "Refactor Mercilessly!" is one of the "practices" of XP, and an expression (XPression?) they like to throw around. Also, yes, any kind of changing can be done, if the tests cover it :-) (except that if you develop new functionality, you must write new tests too) > > 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... > > Hmm. I guess my concern was because it was the only subsection of > 'Fixtures'. Do fixtures need a more topical breakdown or are they > simple enough to sum up in one section? Maybe we can think of some > 'fixture use cases'. I don't think so. I think I just broke the rules. When I added this subsection I was thinking more about some kind of sidebar, not a real subsection - fixtures definitely don't need their own topical breakdown. As there is no provision for "sidebars" or "boxes" in the informal standard format we've been using for these docs, I'll move the note about this issue one level up. []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:[EMAIL PROTECTED] pgp key: http://zope.gf.com.br/lalo/pessoal/pgp Brazil of Darkness (RPG)--- http://zope.gf.com.br/BroDar ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] ZUnit - feedback convocation
On Mon, 4 Dec 2000, Lalo Martins wrote: > > 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. Hmm... actually in that case you may want to axe both "why" and the history. > > 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. Ah, ok I like it. I wonder if "refactor" is the right word; it's very specific and it sounds like any kind of changing can be done. > > 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". Oh, I was thinking of just a simple non-zope unit test to get the flavor, but now that I think about it that's out of scope. Yes, the example after would be better. > > 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. Ah yes, I just went and RTFM. > > 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". > 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... Hmm. I guess my concern was because it was the only subsection of 'Fixtures'. Do fixtures need a more topical breakdown or are they simple enough to sum up in one section? Maybe we can think of some 'fixture use cases'. -Michel ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] ZUnit - feedback convocation
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:[EMAIL PROTECTED] pgp key: http://zope.gf.com.br/lalo/pessoal/pgp Brazil of Darkness (RPG)--- http://zope.gf.com.br/BroDar ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] ZUnit - feedback convocation
On Mon, 4 Dec 2000, Michel Pelletier wrote: > Here's a modified outline I tweaked with my above comments: Oh, I forgot to mention, when we all agree on the outline, the next step would be to write one paragraph for each section, giving a synopsis of that sections scope. This is also a good exercise in making sure 1) the scope is valid and 2) all things are considered. -Michel ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] ZUnit - feedback convocation
On Thu, 30 Nov 2000, Lalo Martins wrote: > Hi all > > I'trying to write a document on ZUnit and Unit Testing in > general, following Michel's and Amos' documentation process. I > wrote an outline, and now I'm stuck :-) anyone with a few free > moments is welcome to take a look and send me some words. Also, > anyone very interested in the subject is welcome to volunteer > for editorial help (read the Process to know what this means). > > Thank you. > I have some suggestions for the outline: 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". What does "refactor mercilessly!" mean? Next section... "Importing ZUnit" requires a whole section? I suggest axing it. I would add an "example" section before moving into fitting it into Zope... What are "Fixtures"? 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. ;) Here's a modified outline I tweaked with my above comments: Unit testing Zope Products with ZUnit by Lalo Martins Unit Testing What is Unit Testing Why do you want to unit test How should it be done Refactor mercilessly! (?) Writing Tests The TestCase class An Example TestCase Interfacing with the Zope environment Fixtures (?) The persistence problem - leaving traces behind (?) Grouping tests in TestSuites Wrapping it all up in a creator function Running the tests The TestRunner object TestResults objects Leaving objects behind for debugging ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] ZUnit - feedback convocation
On Thu, Nov 30, 2000 at 11:52:47AM -0800, Michel Pelletier wrote: > > Where would we find this outline? Uh, attached to my original message. []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:[EMAIL PROTECTED] pgp key: http://zope.gf.com.br/lalo/pessoal/pgp Brazil of Darkness (RPG)--- http://zope.gf.com.br/BroDar ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] ZUnit - feedback convocation
Lalo Martins wrote: > > Hi all > > I'trying to write a document on ZUnit and Unit Testing in > general, following Michel's and Amos' documentation process. I > wrote an outline, and now I'm stuck :-) anyone with a few free > moments is welcome to take a look and send me some words. Also, > anyone very interested in the subject is welcome to volunteer > for editorial help (read the Process to know what this means). Where would we find this outline? > Thank you. > > (BTW, if you can't understand what an "outline" is, read the > process too. Oh what the heck. If you haven't read it, then > read it, it's very cool reading anyway.) Thanks! -Michel ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] ZUnit - feedback convocation
Hi all I'trying to write a document on ZUnit and Unit Testing in general, following Michel's and Amos' documentation process. I wrote an outline, and now I'm stuck :-) anyone with a few free moments is welcome to take a look and send me some words. Also, anyone very interested in the subject is welcome to volunteer for editorial help (read the Process to know what this means). Thank you. (BTW, if you can't understand what an "outline" is, read the process too. Oh what the heck. If you haven't read it, then read it, it's very cool reading anyway.) []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:[EMAIL PROTECTED] pgp key: http://zope.gf.com.br/lalo/pessoal/pgp Brazil of Darkness (RPG)--- http://zope.gf.com.br/BroDar Unit testing Zope Products with ZUnit by Lalo Martins Unit Testing What is Unit Testing Where does it come from How should it be done Refactor mercilessly! Writing Tests Importing ZUnit The TestCase class Interfacing with the Zope environment Fixtures The persistence problem - leaving traces behind Grouping tests in TestSuites Wrapping it all up in a creator function Running the tests The TestRunner object TestResults objects Leaving objects behind for debugging
