The most funny thing about that guy is that he sold that to the management. :-)
On 01 Apr 2008 20:07:21 +0400, Egor Pasko <[EMAIL PROTECTED]> wrote: > On the 0x419 day of Apache Harmony Alexei Fedotov wrote: > > Tim, all, > > > > While it would really great to have 100% API implemented, I broke into > > a sweat when imagined that the quality of our code base may drop in > > result of this approach, if it would not be properly supported with > > tests. This especially concerns sophisticated NotImplementedException > > implementation which is vulenrable to errors. > > > > I come with an idea how we can handle it. I suggest investing into > > automatic tool which would parse bytecode of our methods, make a > > control flow graph and create sets of input parameters which would > > cover all branches in the code. Then we can run methods with given > > parameters and record resulting exceptions or objects (for > > non-serializable objects some hash function such as toString() may be > > recorded). Finally we can generate a test which would check that the > > method produces the recorded result for the set of parameters. > > > > Using this approach we get a test suite with 100% branch coverage and > > 100% pass rate. Providing this as an argument we would beat those who > > might think that "first-order obvious logic" does not give us > > compatible and fully tested implementation. > > > > If creating a control flow graph would be to too complex for an > > applying student, generating typical corner parameters (such as > > objects created by a default constructor) would give us 100% method > > coverage quickly. > > > > Thanks! > > > > :-) > > funny, huh? I know the guy, who tried to do almost the same. Covering > all branches is impossible, of course, but for simple methods it could > work. That is how you get input data for tests. Golden values are > obtained from RI runs. > > Bad, bad joke. > > > > > On Tue, Apr 1, 2008 at 11:12 AM, Tim Ellison <[EMAIL PROTECTED]> wrote: > > > There are a number of interesting student projects being proposed at the > > > moment, and I'd like to add another one for everyone's consideration. > > > > > > It struck me this morning that since we have virtually got the entire > > > platform working well, the remaining pieces could be deduced pretty well > > > by simply describing the expected behaviour using the first-order > > > 'obvious logic' principle. > > > > > > Using this principle we would simply write rules for the missing pieces, > > > and implement an inference engine to evaluate these rules to complete > > > the functionality. While the rules can be written in any language, I'd > > > suggest a good candidate would be the new 'actor participation rules > > > intermediate language 1', and evaluate them using the Java obvious > > > knowledge engine. > > > > > > As an example of the rules we would need: > > > > > > *drag and drop support* Just implement drag. After all, once you > > > are dragging something the only option you have is to drop it. That > > > would be an obvious rule. > > > > > > *rich text format support* Just implement poor text support and > > > invest in compounding instruments code. After a few years the > > > compounding effect will make the text increasing richer. > > > > > > *not implemented exception* Obviously the user's application doesn't > > > want to see this exception. Rather than throw the exception instrospect > > > the stack and just return an object that will pass the application's > > > validation checks instead. > > > > > > I'm unwilling to mentor the project after today, but if anyone else > > > wants to pick up the 'first-order obvious logic' (FOOL) project, writing > > > code in 'actor participation rule intermediate language 1' (APRIL1) for > > > the 'Java obvious knowledge engine' (JOKE) -- then I'd be facinated to > > > see how well it works! > > > > > > For more information see http://tinyurl.com/395w9a > > > > > > Regards, > > > Tim > > > > > > > > > > > > > > -- > > With best regards, > > Alexei > > > > -- > Egor Pasko > > -- With best regards, Alexei
