My take on this is probably the "least resistance path". Magic projects are fairly cheap, so I would organize the tesk blocks as their own small projects, and have the test project invoke those blocks through their artifact IDs.
That works for "good cases". If you need tests with malfunctioning blocks, then I think you are stuck with hand-coded blocks, as we will not guarantee that Magic will not do more validation of blocks in the future, hence automagic generation of a faulty block today may not work in the future. Cheers Niclas ----- Original Message ----- From: "Peter Neubauer" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Friday, September 03, 2004 6:06 PM Subject: Multiple MerlinTestCases in one project? > Hi, > thinking about our project layout, I realize that it is only possible to have > one block generated by the build.xml per project, and there is only one > melrin.properties that gets copied with its deployment directive hardcoded. > > How do you manage multiple MerlinUnit TestCases where you want to test with > different blocks, like test for wrong configurations, wrong deps etc? The > blocks could be generated in other projects as the only artifact, but: > - how do I reference them in the TestCase? I could include them as deps in the > project of course but then only one block is generated again > - I think it would be good to be able to override the merlin.deployment from > within the testcase in order to be able to specify a block from there, but > maybe it would be better to specify an artifact where the block should be > taken from, like the block generating sub project outcomes? > > > If nothing works, you can only have one Merlin integration test that uses > magic-generated block definitions, which I think is not good. That would lead > to hand-coded blocks like in the merlin-unit source which will not work once > you start versioning. > > Just random thoughts. > > /peter > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
