In any case, when using random numbers, set the seed. Without making such tests repeatable, running into an exception or failure will give you the willies no end ;-)
As I wrote, coverage - coverage - coverage! These random tests aren't necessarily going to hit some rare insertion/reorder cases. -W On 11/07/2012, Mark Proctor <[email protected]> wrote: > I think instead of generating ranges, each time, and testing. We should > pre-generate a larger number of test sets and use those. Ideally those > test sets will have random intervals, instead of the regular interval > sets my current approach uses. We should probably introduce negative > numbers. Once we have a large number of data sets we can also generate > start/end points to test against these. > > Atleast this way the tests are deterministic each time, and we can > simply generate more datasets and start/end points if we need to. > > Mark > On 11/07/2012 06:57, Wolfgang Laun wrote: >> I have created another test with repeated deletes, checking against >> another collection maintained in parallel. I have set this up, >> isolated, added cobertura, and see that coverage is already quite >> good. I'll analyze this further, to cover all nooks and crannies. >> Don't start any work that duplicates my own. >> >> Note that my original fix is to simply remove this line; Arrays.copyOf >> does it all. > understood, I used System.arraycopy still as it works in jdk1.5. >> >> public void recurse() { >> >> if ( depth == stack.length - 1 ) { >> // increase the stack if we have used up all space >> // ====> simpl remove this line: stack = new int[depth * 3 ]; >> stack = Arrays.copyOf( stack, stack.length * 3 ); >> } >> >> Cheers >> Wolfgang >> >> >> On 11/07/2012, Mark Proctor <[email protected]> wrote: >>> Wolgang, >>> >>> Nice find, with the change below the tests are now working :) >>> >>> What we need to do now is try and develop some more comprehensive tests, >>> we cannot afford to introduce a new beta memory type, if it has "holes" >>> in it's data iterations. >>> >>> If anyone is good at breaking code, please copy the two classes at the >>> bottom of the email, replace line 150 as per below (thanks wolfgang), >>> and try and generate ranges where the iteratator breaks. >>> >>> For anyone that understands BTree iterations, there are many edge cases >>> on how it traverses that could become broken - mostly depending on where >>> you start and where you finish. Generating tests doesn't guarantee we >>> find them all. >>> >>> Mark >>> >>> >>> On 11/07/2012 00:18, Mark Proctor wrote: >>>> ok I think I see what you mean, it's overwriting the array it's >>>> copying from. have updated it, and running tests now: >>>> if ( depth == stack.length - 1 ) { >>>> // increase the stack if we have used up all space >>>> int[] newStack = new int[depth * 3 ]; >>>> System.arraycopy( stack, 0, newStack, 0, >>>> stack.length-1 ); >>>> stack = newStack; >>>> } >>>> >>>> Mark >>>> On 11/07/2012 00:04, Mark Proctor wrote: >>>>> Wolfgang, >>>>> >>>>> Not sure what you mean, I just checked the src, line 150: >>>>> https://github.com/droolsjbpm/drools/blob/c00d45712f1cf2027ebda9e7df41567cf89c8fcd/drools-core/src/main/java/org/drools/core/util/RBTree.java >>>>> >>>>> >>>>> >>>>> public void recurse() { >>>>> if ( depth == stack.length - 1 ) { >>>>> // increase the stack if we have used up all space >>>>> stack = new int[depth * 3 ]; >>>>> stack = Arrays.copyOf( stack, stack.length * 3 ); >>>>> } The comment doesn't exist there to remove. Mark >>>>> >>>>> >>>>> >>>>> On 07/07/2012 07:05, Wolfgang Laun wrote: >>>>>> Removing the line marked with //>>> helps. >>>>>> >>>>>> public void recurse() { >>>>>> >>>>>> if ( depth == stack.length - 1 ) { >>>>>> // increase the stack if we have used up all space >>>>>> //>>> stack = new int[depth * 3 ]; >>>>>> stack = Arrays.copyOf( stack, stack.length * 3 ); >>>>>> } >>>>>> >>>>>> Cheers >>>>>> Wolfgang >>>>> On 07/07/2012, Mark Proctor <[email protected]> wrote: >>>>>>> I started to write this range indexing class, based on a RBTree >>>>>>> implementation that I lifted from the web somewhere. However it's a >>>>>>> bit >>>>>>> buggy, and large ranges null pointer. Anyone want to work on making >>>>>>> these stable? Once done we can start using them with not/exists >>>>>>> nodes. >>>>>>> Standard joins will take a bit more work, due to some integration >>>>>>> issues >>>>>>> of the tuple structures. >>>>>>> >>>>>>> The two classes can be found in this commit, just try removing the >>>>>>> @Ignore to see the issues, and feel free to add more range tests. >>>>>>> https://github.com/droolsjbpm/drools/commit/c789459c431763581db02653fb7bfafd5742ae1f >>>>>>> >>>>>>> >>>>>>> drools-core/src/main/java/org/drools/core/util/RBTree.java >>>>>>> drools-core/src/test/java/org/drools/core/util/RBTreeTest.java >>>>>>> >>>>>>> Mark >>>>>>> _______________________________________________ >>>>>>> rules-dev mailing list >>>>>>> [email protected] >>>>>>> https://lists.jboss.org/mailman/listinfo/rules-dev >>>>>>> >>>>>> _______________________________________________ >>>>>> rules-dev mailing list >>>>>> [email protected] >>>>>> https://lists.jboss.org/mailman/listinfo/rules-dev >>>>> >>>> >>> >>> _______________________________________________ >>> rules-dev mailing list >>> [email protected] >>> https://lists.jboss.org/mailman/listinfo/rules-dev >>> >> _______________________________________________ >> rules-dev mailing list >> [email protected] >> https://lists.jboss.org/mailman/listinfo/rules-dev > > > _______________________________________________ > rules-dev mailing list > [email protected] > https://lists.jboss.org/mailman/listinfo/rules-dev > _______________________________________________ rules-dev mailing list [email protected] https://lists.jboss.org/mailman/listinfo/rules-dev
