Dfyjkt

I have a Unit test function which worked. When I incorporated ILogger and Moq framework, its not catching exceptions anymore. See Last test below. In debugging the unit test step by step, I know the Exception is thrown. So not sure why its not displaying in Nunit and causing an error.

Error:

Message: Expected: <System.ArgumentException> But was: no exception thrown



using System;
using ElectronicsStore.Models;
using Microsoft.Extensions.Logging;

namespace ElectronicsStore.Service

 public class ParseVendorSupply
 
 private readonly ILogger _logger;

 public ParseVendorSupply(ILogger logger)
 
 _logger = logger;
 

 public VendorSupply FromCsv(string csvLine)
 
 VendorSupply vendorsupply = new VendorSupply();

 try
 
 string values = csvLine.Split(',');
 if (values.Length > 3)
 
 throw new System.ArgumentException("Too much data");
 

 vendorsupply.VendorId = Convert.ToInt16(values[0]);
 vendorsupply.ProductId = Convert.ToInt16(values[1]);
 vendorsupply.Quantity = Convert.ToInt16(values[2]);
 
 catch (Exception)
 
 _logger.LogInformation("An exception was thrown attempting");
 
 return vendorsupply;
 
 

NUnit Test:

public class ParseVendorSupplyNunit
{

 ILogger logger;

 // This Works
 [Test]
 public void FromCsv_ParseCorrectly()
 
 var logger = new Mock<ILogger>();
 var parseVendorSupply = new ParseVendorSupply(logger.Object);
 string csvLineTest = "5,8,3";
 VendorSupply vendorsupply = parseVendorSupply.FromCsv(csvLineTest);
 Assert.AreEqual(5, vendorsupply.VendorId);
 Assert.AreEqual(8, vendorsupply.ProductId);
 Assert.AreEqual(3, vendorsupply.Quantity);
 

 // This does not work anymore,after adding ILogger and Moq
 [Test]
 public void FromCsv_ParseCorrectly_Extradata()
 
 var logger = new Mock<ILogger>();
 var parseVendorSupply = new ParseVendorSupply(logger.Object);

 string csvLineTest = "5,8,3,9,5";

 Assert.That(() => parseVendorSupply.FromCsv(csvLineTest), Throws.ArgumentException);
 

Message: Expected: <System.ArgumentException> But was: no exception thrown

Your code throws the exception inside a try-catch block. Therefore your thrown exception won't leave the function scope. Resulting from that the unit test fails.

 try
 
 string values = csvLine.Split(',');
 if (values.Length > 3)
 
 throw new System.ArgumentException("Too much data");
 

 vendorsupply.VendorId = Convert.ToInt16(values[0]);
 vendorsupply.ProductId = Convert.ToInt16(values[1]);
 vendorsupply.Quantity = Convert.ToInt16(values[2]);
 
 catch (Exception)
 
 _logger.LogInformation("An exception was thrown attempting");
 

You can rethrow the ArgumentException see this stackoverflow link for further guidance. But its an bad idea to use exception for "communication" inside a method. So you could simple move the parameter check, so that it is outside the try-catch block.

Hope that helps

(This isn't to do with Moq.) I think you're aware that you've added a try...catch block in your code which swallows the exception; but you don't understand why the assertion that a particular exception is thrown is now failing. After all you are still throwing the exception, so you're wondering why NUnit doesn't notice.

NUnit doesn't work by observing what your code is doing while it is executing. The only way it can tell if an exception is thrown is if that exception bubbles up to the calling code (the calling code is the assertion that an exception is being thrown, in the test method).

You can think of your assertion that an ArgumentException has been thrown as being a catch(ArgumentException). And because your new code swallows the exception, the assertion in the test won't ever see the exception, so the assertion fails.

As a side note, relating to design, look at how your code behaves if that exception is thrown. The caller just gets back an object (just like if it had worked). So the calling code won't realise anything has gone wrong (which I'd suggest is a bad design).

You could use Moq to verify that the LogInformation method was called once; but that might have been caused by a different exception.

It's also worth pointing out that it's an interesting choice to call LogInformation on an something which will clearly stop the program from functioning. LogInformation is for things which may be of interest. Consider using a different method on the logger, I'd suggest LogError or worse.