On Feb 22, 9:47 am, Terry Brown <[email protected]> wrote: > I think you main point was about test driven design, but you spent a lot of > time emphasizing that unit tests are able to pay permanent attention to > possible issues, i.e. that they never forget to check things. Which obscured > the test driven design part a bit, even though permanent attention is also a > valuable part of unit tests.
My main point is that unit tests are general purpose tools. What makes this work is that it's easy to run one or all unit tests automatically. > Writing unit tests to make sure that a bug which was reported in the wild > does not recur is useful, but not a great advertisement for unit tests, > seeing they didn't prevent the bug hitting the user. You post wasn't about > that, but a lot of the other unit test mentions here are. Correct. My post was about using unit tests in new ways. > So basically, you want code that, given X, produces Y. You write a test > which would test such a piece of code, if it existed, and then write the > code. That's unit testing. The Aha is that you can replace your description by: You want a tool that given any task or design X, verifies (or helps with) some property Y of X. > The unit test approach has provided a probably valuable chance to think about > / clarify the design, and it continues to provide value by catching anything > that breaks the designed functionality. True. > I think what holds me back from using unit tests more is the difficulty in > writing the tests themselves (not the testing framework). A lot of code I > write has some sort of server / client (web or sql server) aspect which makes > constructing a pretend X fiddly. Not that it can't be done, just that it > takes time, and is complex enough to be bug prone itself. And my work > timeframes are not conducive to giving things the time and attention they > need. That's true, without the Aha. With the Aha, the unit test becomes the *easy* way of executing your code. The "test" doesn't need to do testing: it's simply there to help you in whatever way you want. So start by having the test help you do what you want to do quickly, namely run your code :-) @test <set up and run your code> Do you see? Create a Leo file, put this node in the file, then do Alt-6 to run all @test nodes externally. There is only one @test node, so Alt-6 "just works". Because the tests are run externally, they use the latest version of your code: no need to reload Leo. It's a *big* step forward in speed. > When I write something with simpler inputs and outputs, like a parser for all > the conceivable variations on > postgres://foo:[email protected]:5432/dbname.schemaname.tablename then chances are > I would write a simple test. Write the test or not as you please. The @test node above will save you time. > And I'm not sure they help with everything. I spent an hour last night > trying to work out why my generic code for comparing two databases for > differences (after dual entry for QA) wasn't working. This is an example of > a complex X. In the end the problem was forgetting how the record location > reporting function worked, and so not setting some parameters it needed. > I.e. it was working perfectly, I was just using it wrong. So write an @test node that will sniff out the data you want to see. For example, you might want to put a "sniffing" top-level var in the code. The @test node will set this var, something like this: @test import mysteryCode mysteryCode.sniffing = True mysteryCode.run() This is only a general idea. Once you see @test nodes as general tools, not necessarily related to testing, but useful for *any* task you are doing, you have gotten the Aha and its power. Edward -- You received this message because you are subscribed to the Google Groups "leo-editor" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en.
