Blocking point for a first release
2 views
Skip to first unread message
Stefano Maestri
Nov 14, 2009, 4:33:46 PM11/14/09
to tested...@googlegroups.com
I'd like to see the first public release of TestsedBy in next few weeks. IMHO we don't need a lot of things completed before we can go for a release. In particular I'm thinking about just two main things:
bye
S.
- The core need api to create instance of an InterfaceUndertest: when a test is defined on an interface and we are stressing n implementers classes we need to run the same test n times with different instances of that interface under test. I'll take care of this point.
- A maven or ant plugin to run tests using testedby runner. Of course it's fundamental to have it before a release.
bye
S.
Alessio Soldano
Nov 14, 2009, 9:08:33 PM11/14/09
to tested...@googlegroups.com
Hi all,
I've just committed a skeleton for the maven-testedby-plugin at
https://testedby.googlecode.com/svn/plugins/maven/trunk (to have
separate lifecycle from the TestedBy core and simplify the poms) . It
basically has a single mojo doing nothing special for now (it just
touches a file in target dir) and a simple test checking the plugin runs
correctly from within the project itself.
I do plan to provide the actual implementation in the next days, calling
the JunitRunner we have in the TestedBy core. This would basically do
something similar to what we already have in the
InstrumentationTestCase, building up the right bootclasspath and
installing the TestedBy instrumentation agent. It should then be just a
matter of routing the required parameters from the plugin configuration
to the core.
On this topic, as mentioned before, one of the key points is getting the
list of modified classes (tests and tested ones). I plan to act
similarly to what the maven compile plugin does, i.e. simply leveraging
file dates on the filesystem. I'm thinking about a SourceScanner that
select sources (java files, not classes, as I'd leave the class
compilation to the compiler plugin) last modified after the previous run
date of the testedby plugin (last run date need to be saved, of course,
by the plugin itself after each run).
The reason for doing this is that to me it doesn't seem to exist a way
of getting the list of last compiled classes from the compiler plugin,
but if you happen to have better idea than mine... ;-)
That's all for now
Cheers
Alessio
I've just committed a skeleton for the maven-testedby-plugin at
https://testedby.googlecode.com/svn/plugins/maven/trunk (to have
separate lifecycle from the TestedBy core and simplify the poms) . It
basically has a single mojo doing nothing special for now (it just
touches a file in target dir) and a simple test checking the plugin runs
correctly from within the project itself.
I do plan to provide the actual implementation in the next days, calling
the JunitRunner we have in the TestedBy core. This would basically do
something similar to what we already have in the
InstrumentationTestCase, building up the right bootclasspath and
installing the TestedBy instrumentation agent. It should then be just a
matter of routing the required parameters from the plugin configuration
to the core.
On this topic, as mentioned before, one of the key points is getting the
list of modified classes (tests and tested ones). I plan to act
similarly to what the maven compile plugin does, i.e. simply leveraging
file dates on the filesystem. I'm thinking about a SourceScanner that
select sources (java files, not classes, as I'd leave the class
compilation to the compiler plugin) last modified after the previous run
date of the testedby plugin (last run date need to be saved, of course,
by the plugin itself after each run).
The reason for doing this is that to me it doesn't seem to exist a way
of getting the list of last compiled classes from the compiler plugin,
but if you happen to have better idea than mine... ;-)
That's all for now
Cheers
Alessio
Reply all
Reply to author
Forward
0 new messages