Re: establishing logical test order?
"Pigneri, Rocco" <[email protected]> Tue, 24 Jun 2008 11:53:03 -0400
| Newsgroups | gmane.comp.windows.dotnet.nunit.user |
|---|---|
| Message-ID | <D04B62A56C65EA4B860036108BD0A66C0258EC89@boston-ex.lavastorm.local.com> |
However, if you wanted to group tests-which seems like your goal-you have two options. You can use namespaces to hierarchically organize your tests into collapsible, related groups. Alternatively, you can join your four tests together (here, T00-T03) into one test. In this second option, you will see a failure in T00 without running T01 because T00's code will be run before T01 and therefore cancel out execution of T01. I'm not quite sure I understand. I already use classes and namespaces to organize my tests. The trouble is, when they come up alphabetically, they are not organized with any kind of meaning. The namespace "Utilities" is near the bottom while the "ApplicationTests" is near the top, with a bunch of other labeled stuff all mixed around them. This is causing me to have to name my tests with these weird ordering numbers, but this is not really scalable to large projects, or projects that include multiple components. David, I misunderstood you. I assumed that the grouping was more important than the ordering: in other words, that having a collapsible group of four tests would be "good enough". Clearly, I took your example too literally. Sorry about that. Rocco From: David Jeske [mailto:[email protected]] Sent: Monday, June 23, 2008 5:14 PM To: Pigneri, Rocco Cc: [email protected] Subject: Re: [Nunit-users] establishing logical test order? On Mon, Jun 23, 2008 at 11:53 AM, Pigneri, Rocco <[email protected]> wrote: As you mentioned, that is not a natural feature of unit tests: unit tests are by definition unrelated to each other and can be run in any order without introducing failures. Yes, my tests can be run in any order, they are all independent tests of a single piece of functionality. However, all tests depend on the proper functioning of "upstream code". I like to see the failures in order from smallest to largest number of dependencies, because that's where the core problem usually lies. For example, if something broke the core .NET string class, wading through all kinds of other tests is not necessary if your basic-core set of tests right at the top said strings are somehow broken. However, if you wanted to group tests-which seems like your goal-you have two options. You can use namespaces to hierarchically organize your tests into collapsible, related groups. Alternatively, you can join your four tests together (here, T00-T03) into one test. In this second option, you will see a failure in T00 without running T01 because T00's code will be run before T01 and therefore cancel out execution of T01. I'm not quite sure I understand. I already use classes and namespaces to organize my tests. The trouble is, when they come up alphabetically, they are not organized with any kind of meaning. The namespace "Utilities" is near the bottom while the "ApplicationTests" is near the top, with a bunch of other labeled stuff all mixed around them. This is causing me to have to name my tests with these weird ordering numbers, but this is not really scalable to large projects, or projects that include multiple components. It seems like we could do some simple assembly dependency analysis to order the tests into dependency groups. This way tests of bottom-level stuff would naturally be grouped together, and levels would get increasingly complicated (with more dependencies) as they went down. A project which had to many cross-dependencies that it's just one big soup is probably not layered correctly. When doing my own tests pre-NUnit, I build this manually in the makefile test order. However, if we're automating all of this, this seems like the way to do it. Thoughts? - David ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php _______________________________________________ Nunit-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/nunit-users