On Thu, Feb 25, 2010 at 6:31 AM, thyrsus <[email protected]> wrote: > One of my favorite sayings: "If you don't make mistakes, you're not > trying." What's important is to learn, and I think there is a general > lesson here.
So do I. You just beat me to it :-) > The change to @thin semantics for @file changed the > semantics of the .leo file; i.e., earlier versions of Leo could no > longer read the .leo file. One can therefore not rely on new code to > generate - or even preserve - a test case that it could not naturally > generate itself (I'm sure there's a way to hide a test .leo file from > a containing .leo file and write it out, but a read-only blob sitting > in the test tree would be simpler). I.e., transitions are hard, and > need to be tested. I would generalize this to make it simpler: *everything* needs to be tested :-) This includes every "project", however that is defined. In other words, if I change something, I must test *that something*. I think the double-entry bookkeeping analogy is relevant here. The "project", in the sense I have just used it, is one column of the ledger. The actual code is the other column. An example may make this clearer. I'll be changing the files generated by the cacher in Leo 4.8. This requires two sets of unit tests. Code tests will test the modified methods. Project tests will test the files contained in the cache. 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.
