On Thu, 2 Oct 2003 13:38, Vincent Danen wrote: > Build output is great, but if an app doesn't work and no one tries > it, what good is it? Ie. on Corp 2.1/x86_64 apparently no one tried > to do a search in joe... it segfaults every time. Now, granted, not > too many people were able to test that (from my understanding) but a > simple rebuild wouldn't have shown that as being a problem. rpmlint > could be happier than sin, slbd could tell you nothing, but unless > someone has written a program to fire up a program and fiddle with it > automatically and then notify you if there is a problem or something > doesn't operate properly *before* making it publically available, > there isn't much point to an automatic rebuild.
> Auto rebuilds are great for cross-platform *current* development but > trust me... they will absolutely cause nightmares for backporting to > older releases. It shouldn't be hard to bodgy up something to test command-line and curses apps, as in, you walk through a series of tests and record what happened, the framework then feeds in the same events and whinges if the output (and maybe changes to files) isn't the same. That wouldn't guarantee that everything was good, but it would show up obvious problems a lot sooner. To some extent you could do the same with X stuff, although there would be a disadvantage in that things like widgets might change with theming or different versions of the window manager or widget libraries, but you couldn't draw a line around the widgets and tell the test framework to ignore them 'coz the app might break the widgets too. You could semi-automate the tests so that the framework highlighted differences and the operator could say yea or nay (or for something like a clock, draw a line around it and say "ignore this"). None of this would replace manual testing, but it would whoosh through a lot of the boring stuff, saving the, er, interesting bugs for real eyeballs and brains. Cheers; Leon
