I had visual studio create a test for each member in my class. Here's one example:
/// <summary>
///A test for CloseCurrentTextLogFile
///</summary>
[TestMethod()]
public void CloseCurrentTextLogFileTest()
{
Logger.CloseCurrentTextLogFile();
Assert.Inconclusive( "A method that does not return a value cannot be verified." );
}
Based on the assert string, I'm wondering how to test this... Any ideas?
New in version 3.3. unittest.mock is a library for testing in Python. It allows you to replace parts of your system under test with mock objects and make assertions about how they have been used.
Unit testing ensures that all code meets quality standards before it's deployed. This ensures a reliable engineering environment where quality is paramount. Over the course of the product development life cycle, unit testing saves time and money, and helps developers write better code, more efficiently.
Static state methods naturally make themselves fairly untestable, so my suggestion is based around refactoring your code away from static methods.
I would turn Logger into an instance class that takes an IO object in the constructor. That will allow you to stub the IO object and you can Assert that your IO object's Close
method was called.
This is only if you want to make your code 100% testable. Otherwise, I would agree with Mo that if it is not testable, then do not write a forced test...those tend to be very brittle. In the end, you need to be pragmatic about your code. Often a logger is useful to keep static, however as I already mentioned, these tend to be very untestable....so just be pragmatic about your work and don't write tests in the mere effort to get 100% code coverage...that 100% will come with a price...
UPDATE
Here is why this is not truly testable from a dogmatic POV of unit testing. You are not testing a unit of work, but instead you are testing the Logger AND the Logger's dependencies (the IO object in this case). It also makes your tests slower and requiring environmental setup and state (you must have first opened an actual file to close it, right?). These are all bad for unit testing, but ok for integration testing...so it depends on what kind of tests you are writing, also.
I would posit that if it's truly not testable, then it doesn't actually do anything at all, and shouldn't exist ;) Something along the lines of this might work...
Assert.IsNotNull( Logger.File );
Logger.CloseCurrentTextLogFile();
Assert.IsNull( Logger.File );
Or check the status of Logger.FileOpenStatus
or check that Logger.OpenFile(fname)
throws an exception before closing, but not after. There's got to be something in Logger
whose behaviour depends on whatever action CloseCurrentTextLogFile()
performs.
You can check the state of Logger
or you could call some other method on logger that will not produce an error because you called this method, which should succeeded if you had not called the method.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With