Lazycoder

1. 

   Haacked
   October 5th, 2006 - 17:31

   Which version of MbUnit are you running? I assume you made sure your test project references the MbUnit.Framework.dll and that you marked up your test classes with the [TestFixture] attribute and your test methods with the [Test] attribute.

   [TestFixture]
   public class MyTests
   {
   [Test]
   public void SomeTest()
   {
   Assert.Fail(“It failed”);
   }
   }

   Put that class in a class library, compile it, then point MbUnit to that assembly.

   ( REPLY )
2. 

   Scott
   October 5th, 2006 - 19:58

   Well, of course that works. Actually, my code looked like this.

   namespace MBUnitTest
   {
   [TestFixture]
   public class MBUnitTest
   {
   [Test]
   public void FailTest()
   {
   Assert.Fail(“It Failed”);
   }
   }
   }

   I load that in the MBUnit GUI, the test shows up, and it fails as planned. However, the GUI doesn’t show ANY tests in the following code.

   namespace FuzzyDateTextBoxTests
   {
   [TestFixture]
   class FuzzyDateTextBoxTests
   {
   [Test]
   public void TestConstructor()
   {
   FuzzyDateTextBox target = new FuzzyDateTextBox();

   Assert.IsNotNull(target, “Constructor failed”);
   }

   [Test]
   public void TestDateParse()
   {
   FuzzyDateTextBox _fdtb = new FuzzyDateTextBox();
   _fdtb.Text = “07/15/2006″;
   }

   }
   }

   Which confuses me to no end. However, if I add the MBUnitTest code to the FuzzyDateTextBox code and load the assembly in theMBUnit gui, it shows the MBUnitTests, bt not the FuzzyDateTextBox test.

   Any ideas? What am I doing wrong. I swear the code I posted above in the code in it’s entirety.

   ( REPLY )
3. 

   Kevin Dente
   October 5th, 2006 - 21:50

   Em, not that this really solves your problem, but your constructor test will never fail. Calling “new ClassName()” will never return null.

   Also, I noticed that your FuzzyDateTextBoxTests is not declared public. That might be causing your problem where it doesn’t find any tests.

   ( REPLY )
4. 

   Scott
   October 5th, 2006 - 22:10

   Oh, don’t tell me that I forgot that classes and members are private by default. That fixed the problem in this case with MBUnit. I still had other problems with MBUnit that I haven’t been able to fully explain.

   Will the constructor never fail Kevin? Right now, my constructor is nothing more than the default constructor, in the future I may refactor the class to be derived from something else and call the base constructor in my constructor, and my supers constructor may be more complicated. Winform constructors created by the visual designer ALWAYS call “InitializeComponent” in the constructor, which in turn creates many, many other objects, some of whom have more complicated constructors. In fact, during my NUnit attempts, I had a constructor test fail due to a threading issue, The constructor has never failed during runtime, but my test failed. I suspect due to a bug in the testing framework. What do I do about my unit tests if they are dependent upon bugs in the framework? Do I not write unit tests for things that fail for reasons external to my code? It’s one of my gripes about unit testing, how much is too much. What tests the unit tests I write? How do I verify they are testing the correct thing in the correct maner?

   ( REPLY )
5. 

   Kevin Dente
   October 6th, 2006 - 17:46

   I didn’t mean that the constructor would never fail. But it will never return null. In other words:
   FuzzyDateTextBox target = new FuzzyDateTextBox();

   will never result in “target” being null. If the constructor blows up, it’ll throw an exception, and the Assert will never be run.

   ( REPLY )

Leave a comment