0

I have NUnit test code like this:

[Test]
public void TestHHSInterface()
{
    var HHSClient = IOC.container.Resolve<IHHSClient>();

    var s = HHSClient.GetTestMessage("Rupert", "Pupkin");

    Assert.Greater(s.Value.Length, 0);
}

[Test]
public void TestHHSDeliveryInterface()
{
    var Delivery = IOC.container.Resolve<IHHSDelivery>();

    var i = Delivery.GetCount();

    Assert.Greater(i, 42); // was 17; returns 18
}

[Test]
public void TestHHSDeliveryItemInterface()
{
    var Delivery = IOC.container.Resolve<IHHSDeliveryItem>();

    var i = Delivery.GetCount();

    Assert.Greater(i, 42); // was 19; returns 36
}

The TestHHSDeliveryInterface() test (IHHSDelivery) returns 18, so asserting that it is greater than 42 should make it fail. Similary, TestHHSDeliveryItemInterface() returns 36, so its assertion should also fail. But they all "pass":

enter image description here

Also, I don't understand why only two tests are shown beneath \Integration Test\HHSClientIntegration Tests, when there are three, as shown in the code above.

UPDATE

Pierre-Luc Pineault: You might be right, but even when I reverse it:

Assert.Greater(42, i);

...it still passes.

UPDATE 2

I'm not sure what exactly I need to check to follow up on CodeCaster's suggestion to "Check that you're testing the assemblies containing the code you wrote (Debug/Release, different directory), especially given your remark that you see lest tests in the runner than there are in code."

Following are some things that may be noteworthy; let me know what I'm missing/should look for yet.

The Build property page for the Test project says:

Configuration: Active (Debug)
Output path: bin\Debug

App.config contains this line:

<compilation debug="true" targetFramework="4.5" />

HHS.Web.Tests.nunit contains:

<NUnitProject>
  <Settings activeconfig="Default" />
  <Config name="Default" binpathtype="Auto">
    <assembly path="bin\Debug\HHS.Web.Tests.dll" />
  </Config>
</NUnitProject>

(that's the entire contents of HHS.Web.Tests.nunit)

UPDATE 3

In response to some of the comments below (CodeCaster, OnABauer), I don't know if this helps, but the solution has 50 projects (of which I am working on just a few); in "my world," the Startup Projects are three libraries/DLLs, specifically HHS.API, HHS.Web, and HHS.Web.Tests are set to "Start"; all the others are set to "None"

The Debug page of HHS.Web.Tests has "Start external program:" set to "C:\Program Files (x86)\NUnit 2.6.3\bin\nunit.exe" and "Command line arguments:" set to "C:\project\sscs\CStore\Development\Development\HHS.Web.Tests\HHS.Web.Tests.nunit"

UPDATE 4

CodeCaster recommended, "Compare the full path from the test runner with your output path"

How can I determine both things ("the full path from the test runner" and "[my] output path")? Is the path above (C:\project\sscs\CStore\Development\Development\HHS.Web.Tests\HHS.Web.Tests.nunit) the test runner path? Or...???

UPDATE 5

As can be seen in the scream shot above, TestHHSDeliveryInterface shows up in the list of tests (supposedly) being run. So one would think that TestHHSDeliveryItemInterface would show up there, too. After all, all of the places where TestHHSDeliveryInterface appears in the code, TestHHSDeliveryItemInterface does, too:

HHSClientIntegrationtests:

[Test]
public void TestHHSDeliveryInterface()
{
    var Delivery = IOC.container.Resolve<IHHSDelivery>();

    var i = Delivery.GetCount();

    //Assert.Greater(i, 42); // was 17; should return 18
    //Assert.Greater(42, i); <= same result (passes)
    // Seeing if it's running at all
    Assert.Fail(); // <= Test still passes, so something is very fishy here...
}

[Test]
public void TestHHSDeliveryItemInterface()
{
    var Delivery = IOC.container.Resolve<IHHSDeliveryItem>();

    var i = Delivery.GetCount();

    Assert.Greater(i, 42); // was 19; should return 36
}

HHSClientPlayTest:

[Test]
public void TestHHSDeliveryInterface()
{
    var HHSDelivInterf = IOC.container.Resolve<IHHSDelivery>();
}

[Test]
public void TestHHSDeliveryItemInterface()
{
    var HHSDelivItemInterf = IOC.container.Resolve<IHHSDeliveryItem>();
}

HHSClientUnitTest:

[Test]
public void TestHHSDeliveryInterface()
{
    var HHSDelivInterf = IOC.container.Resolve<IHHSDelivery>();
}

[Test]
public void TestHHSDeliveryItemInterface()
{
    var HHSDelivItemInterf = IOC.container.Resolve<IHHSDeliveryItem>();
}

And every place in the code where IHHSDelivery exists, there is a corresponding block of code for IHHSDeliveryItem...

B. Clay Shannon-B. Crow Raven
  • 8,547
  • 144
  • 472
  • 862
  • 2
    Isn't `Assert` stuff implemented like `(expected, actual)`? Look at the intellisense, I'm pretty sure it should be `Assert.Greater(42, i)`. – Pierre-Luc Pineault Jun 30 '14 at 22:53
  • 1
    That is true for the Assert.Equals method but not for Assert.Greater. See the documentation http://www.nunit.org/index.php?p=comparisonAsserts&r=2.2.8 –  Jun 30 '14 at 22:59
  • @Phaeze Thanks for the clarification. I'm not using NUnit, so I wasn't sure if it was following the classic C#/Java Assert format. – Pierre-Luc Pineault Jun 30 '14 at 23:03
  • What do you mean you're not using Nunit, you lost me there? –  Jun 30 '14 at 23:04
  • 2
    Check that you're testing the assemblies containing the code you wrote (Debug/Release, different directory), especially given your remark that you see lest tests in the runner than there are in code. – CodeCaster Jun 30 '14 at 23:05
  • 2
    I am leaning towards the test runner isn't running the test properly for some reason (no examples come to mind) you can try to force a failure by putting in an Assert.Fail(). If it still passes then the test runner is where you're problem is. –  Jun 30 '14 at 23:05
  • @Phaeze: I think Pierre-Luc means he's not using NUnit, but was making assumptions about how NUnit works based on prior experience with other tools. – B. Clay Shannon-B. Crow Raven Jun 30 '14 at 23:16
  • @Phaeze: Good idea => as you suggested, I used Assert.Fail() and it still passes, so obviously my test, as it stands, is not worth the ether it flows on. – B. Clay Shannon-B. Crow Raven Jun 30 '14 at 23:19
  • 1
    I prefer the fluent syntax, so usually write something more like `Assert.That(s.Value.Length, Is.GreaterThan(0))` just for clarity. However, CodeCaster's suggestion of checking that you're actually running the right assembly from the correct directory is probably worth double- and then triple-checking. – ClickRick Jun 30 '14 at 23:51
  • @ClickRick: Yeah, I responded to that in Update 2. Something is obviously past the date in a Scandinavian country. – B. Clay Shannon-B. Crow Raven Jun 30 '14 at 23:52
  • 1
    Have you tried the command-line runner, `nunit-console.exe`? *(Or `nunit-console-x86.exe` depending on your application/OS)* – ClickRick Jun 30 '14 at 23:57
  • @ClickRick: No, I don't know anything about it; I might have to czech that out tomorrow. – B. Clay Shannon-B. Crow Raven Jun 30 '14 at 23:58
  • Quit the test runner, do a Clean and Rebuild of your solution and don't ignore any errors or warnings you receive. Compare the full path from the test runner with your output path. – CodeCaster Jul 01 '14 at 06:15
  • 2
    I'd make sure that the unit tests are being included in your build. It looks like they're just testing against an earlier version of the tests you wrote. I'm not sure how your code is laid out but I sometimes add a unit test project and for some reason I have to manually add it to the build, otherwise it won't get included in "Build Solution" – OnABauer Jul 01 '14 at 09:24
  • 2
    As well as comparing the full path of the files I'de check the creation date of the files. It looks like your tests could be being run on an earlier version of the tests (that would explain why only two tests are showing up for HHSClientIntegration Tests). Just to be on the safe side I'd rebuild all and make sure the creation dates for the physical test files are updating. – OnABauer Jul 02 '14 at 07:09

1 Answers1

2

Instead of specifying a .nunit file in the project's Start Options, specify the test dll name without any path info. If this file is being rebuilt each time, it should guarantee you are loading the correct file.

If you set a breakpoint on the Assert, does the return value match what you expect? If not, you are either dealing with nunit-agent.exe or you are not recompiling your test assembly each time.

To verify you are using the correct assembly, use Process Explorer from the Sysinternals Suite to locate dll actually loaded by NUnit. Delete that assembly and recompile.

Community
  • 1
  • 1
Pedro
  • 12,032
  • 4
  • 32
  • 45