If you're beasting a single test that won't take advantage of multiple processors...
On Sat, Aug 15, 2020 at 10:31 AM Robert Muir <[email protected]> wrote: > Is a beasting script needed with gradle? Can't you do it efficiently with > a simple shell script loop? If you have the gradle daemon running, overhead > will be minimal (unlike ant) ? That's kinda the point of the daemon right? > > Here's the kind of loop i typically use for stuff like this, right from > bash console: log the output for each run to individual files and just > print the exit status so i can see progress as it goes. > > for i in {1..100}; do > gradlew test ... > /tmp/$i.log 2>&1 > echo -n $? > done > > On Sat, Aug 15, 2020 at 9:37 AM Erick Erickson <[email protected]> > wrote: > >> I often use “The best Lucene / Solr beasting script in the world. TM.” ( >> https://gist.github.com/markrmiller/dbdb792216dc98b018ad). >> >> The it struck me out of the blue (well actually since I’ve been beasting >> for SOLR-14750 a lot), “Gosh, when we remove Ant from trunk I won’t be able >> to use the beast script”. >> >> So I wanted to ask how many people use it and what people’s thoughts are >> about what to do after we remove Ant from trunk. Off the top of my head, >> options are: >> >> 1> find some Gradle magic that will do this. >> >> 2> modify the script to work with Gradle instead (if possible). >> >> 3> just do without it or an equivalent (booooo!) >> >> 4> In the brave new world of containers, is there a simple way to fire up >> N simultaneous but independent instances of the _same_ test and keep them >> running until the limit is reached? We’d need to be able to change code and >> fire up the script without too much work, and having the results all >> written to beast/res/1/(1, 2, 3, 4, 5)/stdout is necessary, as well as >> being able to have an “all succeeded” message at the end. >> >> 5> ??? >> >> I’ll ping mark and see if he’s got some magic that he’s been using with >> the reference impl. >> >> I don’t think tests.iters is a good replacement for two reasons: >> >> a> part of the usefulness of the beasting script is that it fires up a >> bunch of parallel tests, stressing the system. >> >> b> last I knew, it needs to be run for pure unit tests, and Solr has lots >> of tests that are not. >> This is from Robert Muir from some time ago specific to Ant, would it >> still be valid? >> >> ————--- >> Long answer: It has been discussed on the list several times. >> tests.iters does not do what a lot of people seem to think. >> From what i remember: it creates your test *class* a single time and >> runs stuff repeatedly... I think only (new *instance*, setup, >> teardown, etc). I don't even think it runs e.g. beforeclass/afterclass >> stuff between iterations either, but that still wouldnt make it >> completely safe anyway unless the whole class was recreated (a test >> could leave a static variable in a different state or something). >> >> So if your test isn't a pure unit test, its probably not ready for >> tests.iters. Just use ant beast, it works :) >> ----------- >> >> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> >> -- http://www.needhamsoftware.com (work) http://www.the111shift.com (play)
