If anyone decides they want to get into this, I wrote a open source Java CFML parser a while back that was 90% complete... if you start testing it out, I could probably do more work on it to get it up to speed.
Let me know. Mark On 10/31/07, Peter Bell <[EMAIL PROTECTED]> wrote: > > > the question I'd like to ask then is how do you know if you've written > > enough unit tests? > > Errr, my eyes are bleeding and my fingers are sore? > > :-> > > More seriously, code coverage is cool but doesn't solve the problem either. > It lets you know which lines are exercised, but the more meta-programming, > dynamic generation, mixins and the like you do, the less meaningful those > metrics are. Do you count code coverage of the classes that you gen, write > to disk and then include at runtime? What about coverage of object based > mixins or class based mixins on a per class basis? Maybe you mixin a method > that's tested in UserService but that would break within the ProductService > class . . . > > Also, it only checks that you exercise the code - not that you fully > exercise it. You may run a method, passing it a positive integer, so you've > covered the code. But what about 0's, negative integers, invalid types or > even passing objects in there? What about fractions? All could break > "covered code" (I'm assuming we DON'T have control flow code for these - > ironically, the better your code is in terms of having special code to catch > exceptions, the more likely that code coverage tools will show your tests > aren't exercising the code for the special cases - fi you don't HAVE code > for the exceptions, you'll pass the code coverage and not know there is a > problem until your site crashes when someone says that they have -2 > dependent children. > > The best answer to this flows from the requirements. You come up with a > collection of use cases, for each method that could be called by each > screen, you come up with a list of possible inputs/assertions and expected > outputs. There is no practical way to prove correctness of an app (unless > you program in Z or something), but going through each method in each use > case is a good starting point and will probably give you better coverage > than a simple code coverage tool. > > Not to say code coverage isn't useful, but it isn't the whole story, and I > wonder if it isn't a bit of a red herring in a dynamic language like CF. > Thoughts? > > Best Wishes, > Peter > > > > On 10/30/07 5:28 PM, "Barry Beattie" <[EMAIL PROTECTED]> wrote: > > > > >> It seems like this question comes up more and more often. > > > > that's because some ppl have seen it put to good use in the Java world > > (inc me) and find the case for their use worthwhile, if not > > compelling. > > > > the question I'd like to ask then is how do you know if you've written > > enough unit tests? > > > > > > > > > > > > -- E: [EMAIL PROTECTED] W: www.compoundtheory.com --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "CFCDev" 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/cfcdev?hl=en -~----------~----~----~----~------~----~------~--~---
