On Feb 25, 9:50 am, "Edward K. Ream" <[email protected]> wrote: > On Thu, Feb 25, 2010 at 9:26 AM, Kent Tenney <[email protected]> wrote: > > I've heard of the workflow which says the first step in approaching > > a bug is to write a test which fails because of the bug, this is done > > before the code is touched.
There is a tension here. We don't want the unit testing process to perturb the code. A recent bizarre unit testing bug arose because I stupidly changed what the code under test did when g.app.unitTesting was True! It's ok for Leo's code to pass data to unit tests, but it *must not* do more than that. This suggests that one aspect of design is designing for unit tests. For example, the present atFile.read code has a large number of on/off switches. It would take a *lot* of tests to test all combinations of those switches. It might be possible to hide the switches from the public api by defining wrappers. We would then need unit tests only for these wrappers, not for sets of switch settings that are not, in fact, used. This may not be a great idea, but it is an example of what I mean. The issue has relevance for Leo 4.7.1. Yesterday I attempted, and failed, to create a unit test that would verify directly that reading an external file with file-like sentinels would set the corresponding @file node dirty. This is obviously an important test, but I don't want to be making significant changes to complex (and unrelated) code just to get c.new to be inited *exactly* like a file opened by name. I'll try again later today, but I may have to settle for a hand test... 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.
