Menu
▾
▴
Re: [junit] RE: [Junit-devel] Making JUnit more pluggable for add-ons
|
From: <ev...@ql...> - 2001-11-27 21:15:24
|
I'm a little confused. If you are using an instrumented VM, why would you want the TestRunner to launch it? Don't you normally launch the TestRunner from within a VM? java junit.textui.TestRunner becomes: myvm junit.textui.TestRunner It's easy enough to use an <exec> statement in ANT or use ANT's extension mechanism to have it use a different VM for your unit test target. Are you looking to have the TestRunner run in a different VM from the testcases? In that case, a good generic mechansim would be to have a TestCaseProxy or some such which causes a test case to be invoked in a different VM. I have had to do something like that in the past for a client's project. The TestCaseProxy invoked a set of tests in a remote VM via RMI. Unfortunately, this was using a different test harness and the code is not available to me now. On Tue, 27 Nov 2001, Michael Silverstein wrote: > < at the request of several people, I'm continuing to cross-post. Anyway, > jun...@li... seems to have a lot of noise from build > updates that are probably not interesting to most people and would > discourage them from subscribing > > > .... > > In http://www.geocrawler.com/archives/3/8174/2001/7/0/6256758/ there is a > description of a TestRunListener interface that would accomplish what I need > for being notified when a test starts and ends. The thing I didn't mention > is that for the purpose of profiling I will be launching the test in an > instrumented VM, so I need to completely override the present test execution > scheme. > > At first blush, one might approach this by implementing a new TestRunner > that launches an instrumented VM, but I would have to do this several times > to support each TestRunner presentation, which is not practical. That's why > I proposed a simple decorator, because it requires the least rework of the > existing architecture (simplest thing that could possibly work). Perhaps > once the model and view have been sufficiently separated, the TestRunner > approach will become more practical. > > ^^^^^^^^^^^^^^^^^^^^^^^^^ > Mike Silverstein > SilverMark, Inc. > The object testing company > http://www.silvermark.com > > > -----Original Message----- > > > > Problem statement > > ----------------- > > I am adding some additional profiling and metrics to JUnit test execution. > > In order to do this I need to plug in to JUnit in such a way as to perform > > some operations before and after test execution, and to extend the test > > results to contain the new metrics. Presently the framework does not allow > > me to do this without altering it. > > > > Process > > ------- > > I can either graft a new branch on to the JUnit source tree that contains > > various extensions built in and give it a new name (like JUnit XYZ or > > whatever) or provide some tweaks to the present framework that satisfy my > > needs in the hope they are accepted as part of the next version. > > The purpose > > of this email is to start a discussion about this so that whatever changes > > are necessary fit in with the architectural spirit of JUnit and > > are suitable > > for inclusion in a base release. If possible, I'd like to wrap this up and > > make it publicly available by the end of the year. > > > > Note: I realize test cases are the recognized currency for > > articulating new > > functionality, so once there is agreement in principle to an > > approach, I can > > provide test cases to provide more detail. > > > > Wrapping test execution > > ----------------------- > > I need to be able to start profiling immediately before a user test starts > > and end profiling immediately afterward. One approach is to wrap the user > > test class that is presently instantiated in > > junit.runner.BaseTestRunner.getTest(String) with a TestDecorator subclass > > instance that manages profiling during test execution. Creating the > > decorator sounds like a job for factory method [Gamma95]. > > > > Extending the results > > --------------------- > > This is presently not easy because all the various test runners > > (subclasses > > of BaseTestRunner) implement their own createTestResult() method, > > where the > > reference to the TestResult class is hard coded. I'd like to be able to > > specify that dynamically as well. This also sounds like a job for factory > > method [Gamma95]. > > > > Toward a unified pluggable configuration approach > > ------------------------------------------------- > > A possible approach is to employ the abstract factory pattern [Gamma95] > > where the concrete factory class contains factory methods for the above > > classes and others, is specified in the preferences file or > > elsewhere. This > > sort of architectural change would substantially enable the sort of > > pluggability that I'm after. > > > > Some questions and observations about the framework > > --------------------------------------------------- > > Having spent some time digging into JUnit I have the following > > questions and > > comments: > > > > - The preferences file is read in more than one place: > > - junit.runner.BaseTestRunner.readPreferences() > > - junit.runner.TestCaseClassLoader.readExcludedPackages() > > I could be wrong but it seems like this is redundant execution, > > especially > > since the preferences is kept in a static variable. > > > > - The preferences (junit.runner.BaseTestRunner.fPreferences) is static. It > > strikes me that this hampers testability of the framework because it makes > > it difficult to isolate the framework preferences from the preferences for > > instances of framework classes under test. > > > > - The TestResult class provides semantics for running and stopping tests. > > This seems like a stretch for a results class, which I would imagine is > > primarily a container for execution metrics and other downstream > > information. > > > > - The TestRunner variants are very tied to presentation layer. I see this > > has been discussed at length in the past so I won't belabor it. > > > > - It seems that since all the methods in junit.framework.Assert are static > > and it does not hold any state, there is really no need to make this class > > the root of all tests, except for the convenience of not > > prefixing assertion > > methods with 'junit.framework.Assert'. I'm sure I'm missing > > something here. > > > > References > > ---------- > > [Gamma95] Erich Gamma et al. "Design Patterns - Elements of Rusable > > Object-Oriented Software", Addison-Wesley, Reading, MA, 1995. > > > > ^^^^^^^^^^^^^^^^^^^^^^^^^ > > Mike Silverstein > > SilverMark, Inc. > > The object testing company > > http://www.silvermark.com > > > > > > > > _______________________________________________ > > Junit-devel mailing list > > Jun...@li... > > https://lists.sourceforge.net/lists/listinfo/junit-devel > > > > ------------------------ Yahoo! Groups Sponsor ---------------------~--> > E-mail viral marketing - with FastTree > Email to 50. You might reach 500. > Unlimited use and tracking, $20/mo. > http://www.fasttree.com/s/11.htm > http://us.click.yahoo.com/UGVLpD/MJRDAA/yigFAA/NhFolB/TM > ---------------------------------------------------------------------~-> > > To unsubscribe from this group, send an email to: > jun...@ya... > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ > > > -- Eric Vought Chief Technical Officer - QLUE Consulting, Inc. ev...@ql... toll-free: 888-771-3538 RTP area: 919-816-9901 |