All, I've not been around here long enough to know/care _where_ tests are located. Nor have I studied the tests in question (so I probably don't know what I'm talking about :-) )
However I have been a developer long enough to know that ideally all tests should be self contained. Tests should never rely on arbitrary existing env. variables and ideally not on the presence of any subsystems that the build env doesn't already need to know about. If it is possible for a test to work, it should work. Low-level function level tests can often be platform independent and self-contained, higher level tests can often use a loop-back approach. Tests which rely on special environments outside the source code should be skipped if those environments are not available. Graphics based tests should (in this case) be rendered in a software renderer and output images (png etc) compared to a reference image for Pass/Fail tests. Tests which rely on humans to pas/fail them are useful for quick debugging but are not helpful as part of an automated regression testing process. IMHO tests should either PASS or be automatically SKIPPED they should never FAIL. my 0.02c worth Now I suppose I should study the tests, but probably only after I've looked at simplifying the build process. cheers Kim On 19/12/2010, at 2:51 PM, Carsten Haitzler (The Rasterman) wrote: > On Sat, 18 Dec 2010 17:14:02 +0100 Thomas Sachau <to...@gentoo.org> said: > >> Attached is a build log with the failures. > > ok. since your position is that tests should work even if u enable them and > they cant connect to a display, or that we need to go fine-graining tests just > so you can --enable things that you wouldn't understand were they to fail, > i've > decided to remove all tests from src trees. > > it seems gentoo (some) users and/or developers are unable to take the hint of > "you enabled tests manually yourself - they are never enabled unless you > explicitly enable them, then that makes it your problem". you shot yourself in > the foot and then ask us why it hurts. we get the build logs that told you the > problem (ecore_x_init fails - can't connect to a display somewhere) in the way > intended (for developers to run test suites to see if they broke something > fundamental while working on code), then that just wastes our time. > > i'm grumpy because i tried to explain it the short way (on irc) "you enabled > tests - they fail. don't enable them. if u cant run them in their expected > test > env they will fail". that fell on deaf ears, so the tests are summarily > removed > out of the src trees. if anyone has an issue with it - talk to thomas and/or > gentoo developers. this week i replied to his issue twice. once in a trac > ticket and again here. > > the above is here for the benefit of the rest of e devs as to why i just did > this. > > -- > ------------- Codito, ergo sum - "I code, therefore I am" -------------- > The Rasterman (Carsten Haitzler) ras...@rasterman.com > > > ------------------------------------------------------------------------------ > Lotusphere 2011 > Register now for Lotusphere 2011 and learn how > to connect the dots, take your collaborative environment > to the next level, and enter the era of Social Business. > http://p.sf.net/sfu/lotusphere-d2d > _______________________________________________ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel ------------------------------------------------------------------------------ Lotusphere 2011 Register now for Lotusphere 2011 and learn how to connect the dots, take your collaborative environment to the next level, and enter the era of Social Business. http://p.sf.net/sfu/lotusphere-d2d _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
