That's pretty much it but you could instead create a TestSuite that contains multiple TestCases. There is a bunch of framework code for data-driven testing in Gallio.Framework.Data. Some of this may be useful to use however I expect you will find it easier to keep it simple and generate combinatorial tests using nested loops. Jeff.
_____ From: [email protected] [mailto:[email protected]] On Behalf Of mark Kharitonov Sent: Monday, August 24, 2009 9:05 AM To: [email protected] Subject: MbUnit Re: How to extract the test Metadata from within the SetUp method? On the subject of manually writing combinatorial tests. I have a question here. A combinatorial test appears just once in Gallio.Icarus. It serves as a well defined report unit, under which the actual test steps appear. How can I achieve the same effect with manually created combinatorial tests? Looks like I need to create a test and then the test steps as children of that test, is that right? BTW, Is it possible to reuse Gallio code when manually creating combinatorial test steps? Thanks, On Sat, Aug 22, 2009 at 10:37 PM, Jeff Brown <[email protected]> wrote: At runtime you can obtain information about the current test using TestContext.Current.Test. What you cannot do at the moment is to easily obtain information about other tests. Well, in principle the whole test model is fully accessible but in practice you'll find it to be inconvenient to work with. I have been thinking about what you said with respect to regenerating dynamic test cases from static ones for testing entities of different types. I think I would recommend that you instead implement a new contract verifier. Take a look at IContract, VerifyContractAttribute and some of the existing contract verifiers like EqualityContract. You could pretty easily implement an EntityContract of your own. Basically a contract generates test cases in the same manner as a [StaticTestFactory] but they are packaged in a more convenient form for reuse. However, contracts then have the same disadvantage as the static & dynamic test factories in that they do not (yet) provide convenient abstractions for representing data-driven test cases. I expect that this can be remedied with a little work but it's out of scope for v3.1. As a result you will have to write your own combinatorial test generators and such but it's pretty trivial code. Anyways here's what an entity contract might look like to the user: [VerifyContract] public readonly EntityContract MyEntityContract = new EntityContract<MyEntity>(... options...); Jeff. -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Mark Kharitonov Sent: Saturday, August 22, 2009 11:52 AM To: MbUnit.User Subject: MbUnit How to extract the test Metadata from within the SetUp method? I mean, besides using the reflection on the test method by its name. I expected to find something like GetMetadata method on the Test class, but there is none. -- Be well and prosper. ============================== "There are two kinds of people.Those whose guns are loaded and those who dig." ("The good, the bad and the ugly") So let us drink for our guns always be loaded. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "MbUnit.User" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/mbunituser?hl=en -~----------~----~----~----~------~----~------~--~---
