On Mon, 2007-09-10 at 11:18 -0700, James Takahashi wrote: > Subrata Modak <[EMAIL PROTECTED]> wrote on 09/10/2007 > 02:10:13 AM: > > > > We have been hearing some couple of fuming faces for LTPś Broken > Test > > cases, commonly known as false positives. Yes there are hundreds of > such > > Test cases which has not been updated for quite some time. So, the > > functionality they test may have undergone changes during that > period. > > Hence, we need to revisit/rework the way they report PASS or FAIL. > > Following is attached an initial set of Test cases, which according > to > > [EMAIL PROTECTED] reports false positives. Our aim is to make this as > > comprehensive as we can and then swiftly act upon these erring test > > cases before they loose their value. I would request you to add your > > entries to this list (as well as the reasons/observations/conditions > for > > which they report false positives). We would work out to include > fixes > > for them. > > > One other thing you might want to consider that is related to the > issue > of false positives... > > The number of new tests being added to the tarball has increased > pretty > dramatically since you took over, and some of those tests seem > to be generating false positives of their own. > > I think new tests are a good thing, but in the interest of reducing > false positives, it would be nice if you had some sort of staging > mechanism > for acquiring some burn-in time on new tests before causing them to > run > as part of the default test suite. > > For example, perhaps have a "$LTPROOT/runtest/new" directory that only > gets run > if the user sets some 'extended tests' option? > > Just my $.02. >
You are correct. The Burn time is already inherent before its' Authors submitted thier patches. They probably tested on various platforms/architectures under varying conditions. Moreover i did a thorough testing before integrating them to LTP. Still we will have some broken cases. Having said that, i would highly appreciate if some of you (who detects a break) also submits a solution (patch) for the same. We will debate over the problem and solution, before final merge. This helps enriching quality of the said testcase(s). --Subrata-- ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Ltp-list mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/ltp-list
