Gregory, I observed similar quirks with paths while intergrating kernel tests into build. AFAIU the "Grand Design" is the following: there are abstracted targets and isolated component descriptors; build system iterates through all components and tries to apply given target to each component. So there are various tricks to stop it running tests multiple times a-la "recurring inclusion protection" in C headers. I do not grok how it calculates dependencies though, but it is quite easy to drive it mad and it starts doing wrong sequence of targets and picks wrong components etc. So I just snipped off that fanciful machinery and made simple subant for "kernel.test" target - see its definition in build/make/build.xml, and compare with nearby "smoke.test" one.
2006/10/31, Gregory Shimansky <[EMAIL PROTECTED]>:
Geir Magnusson Jr. wrote: > Gregory Shimansky wrote: >> I don't want to create a huge discussion out of it like most [testing] >> discussions become. Just want to know your arguments to create one >> more tests category. > > Because the current frameworks are... wacky. I can't turn off smoke > tests without *recompiling* the test. The c-unit test rig is kinda > cool, but inappropriate. Maybe kernel could be used. Ok I see your point. I'll try to create my own tests building and running category, maybe if it is good enough we'll transfer smoke tests to it in the future.
I agree, better to add separate category as there is certain specific and building and running JVMTI tests. Indeed kernel tests could be used as a sample.
> it sounds like you just want to launch a set of conventional junit tests > with a special invocation of java to get the agent running, right? Hmm I didn't think of using junit before your suggestion. Now that I think of it, it can probably work for me. It appears that it is possible to pass special <vmarg/> to <junit> task. I'll give it a try. >> Now that I looked at the smoke tests build more closely and found a >> paths problem which I don't know how to fix, I am also inclined to >> make my own build script to have it separated. <joke>I would at least >> know how it works and own this secret like someone who wrote smoke >> build script does.</joke> > > That's what I was hoping to avoid. Something conventional. JUnit or > TestNG (TestNG! TestNG!), and a separate ant script invoked from main > script. Hmm I am not familiar with TestNG at all. I'll try junit first. -- Gregory Shimansky, Intel Middleware Products Division
