Develop Reference

Mock log file for unit test in .NET Core application

In my C# application I have a getLogFile which is set by calling the GetLogFile() method:
private static string getLogFile = GetLogFile();
private static string GetLogFile()
{
var fileTarget = (FileTarget)LogManager.Configuration.FindTargetByName("file-target");
var logEventInfo = new LogEventInfo();
string fileName = fileTarget.FileName.Render(logEventInfo);
if (!File.Exists(fileName))
throw new Exception("Log file does not exist.");
return fileName;
}
I'm now trying to unit test some code which will require the getLogFile variable to be set. I'd like to mock this in some way as I'd like to use specific log data for my test but am not sure how to go about it. How can I do this?

"Mocking" a private static field or method is not really possible.
To have this kind of method as a private member of another class smells like a violation of Single Responsibility Principle.
You should probably refactor this behavior to a separate class and hide it behind an interface. I'm not entirely sure what the NLog Code does, but what your method really seem to do is not providing the log file, but the name of the log file (you return fileName) So this is how it could look like:
public interface ILogFileNameProvider
{
string GetLogFileName();
}
public class DefaultLogFileNameProvider : ILogFileNameProvider
{
public string GetLogFileName()
{
// your code ommitted
}
}
It's just an example on how you can handle it. The naming/structure and how you use it is up to you.
This interface can then be injected in the using class that currently has the private methods. This dependency/call can be mocked.
Usage with constructor injection:
public class LogFileNameUsingService
{
private readonly ILogFileNameProvider _logFileNameProvider;
public LogFileNameUsingService(ILogFileNameProvider logFileNameProvider)
{
_logFileNameProvider = logFileNameProvider;
}
}
Test with xUnit and AutoMocker as example:
[Theory]
public void TestWithMockedLogFileName()
{
//Arrange
var mocker = new AutoMocker();
var logFileNameProviderMock = mocker.GetMock<ILogFileNameProvider>();
logFileNameProviderMock.Setup(x => x.GetLogFileName()).Returns("your mocked file name.log");
var sut = mocker.CreateInstance<LogFileNameUsingService>();
//Act
var result = sut.TestedMethodWhichUsesLogFileName();
//Assert whatever you want to test
}
This also allows you swap out the current logic to get a log file later without changing the logic of the existing class.

How to dynamically invoke a class based on a string?

Can you give me some guidance to dynamically load class based on name. The name is provided as a argument at runtime.
static void Main(string[] args)
{
...
}
Let's say my argument is "parrot" then I would like to load my parrotProcessor class. If my argument name is "snake" then I load my To make snakeProcessor. Of course this mean I have a parrot and snake processor class that inherit an interface IProcessor. I don't know what could be the list of all processor. this list is maintained by other developers and they can create what they want.
Example of my processor interface:
public interface IProcessor
{
void Process();
}
And in my Program.cs
static void Main(string[] args)
{
var processor = GetProcessor(args[0]);
processor.Process();
}
My question is what should I do in GetProcessor() method?
Here is what I have at this moment:
private IProcessor GetProcessor(string name)
{
switch (name)
{
case "ant":
return new AntProcessor();
case "parrot":
return new ParrotProcessor();
case "snake":
return new SnakeProcessor();
default:
throw new ArgumentException("Case not found");
}
}
But this mean I must updated this ugly switch each time I create a new processor specialized class. This is not possible. I can do it now for development but not for long term.
What are the solutions? Should I use something similar to DI with NInject or am I mixing everything? Can I simply use the Invoke method? And why Invoke or DI? I know this question is kind of open question but it is something that happen often in code of many people so I suppose there is unique best practice about it.

You can use something like the following
var type = Type.GetType("MyFullyQualifiedTypeName");
var myObject = (MyAbstractClass)Activator.CreateInstance(type);
You need to do some string modifications like taking the word, adding the processor string and making sure that all the processors are at the same place.
If you are certain that the type is in the current assembly, simply fully qualified name by this
Activator.CreateInstance(Type.GetType("SomeProcessor"));

First of all, there is absolutely nothing wrong with using a switch block as you are doing. It gets the job done, and it serves as an explicit source of truth with regards to the interpretation of the command-line parameter. It also acts as a whitelist, preventing users from passing a class name that maybe you don't want them to instantiate. Yes, you have to update it every time you add a new class, but you're already adding the class itself, so you are already in a situation where a new version and deployment will be needed.
That being said, there are various reasons why you'd rather have the ability to look up a command line parameter and automatically know which type to instantiate. That is trivial to do with a Dictionary<string,Func<IProcessor>>:
this.Map = new Dictionary<string,Func<IProcessor>>
{
{ "ant", () => new AntProcessor() },
{ "snake", () => new SnakeProcessor() },
{ "parrot", () => new ParrotProcessor() },
{ "lizard", () => new LizardProcessor() }
};
Then you would handle a command-line parameter like this:
//Use the string to look up a delegate
var ok = this.Map.TryGetValue(textFromCommandline, out var func);
//If not found, user entered a bad string
if (!ok) throw new ArgumentException();
//Invoke the delegate to obtain a new instance
IProcessor processor = func();
return processor;
Once you understand the concept of using a map in this way, you can come up with a scheme to populate it automatically, e.g
this.Map = assembly.GetTypes()
.Where( t => typeof(IProcessor).IsAssignableFrom( t ))
.ToDictionary
(
t => t.Name,
t => new Func<IProcessor>( () => Activator.CreateInstance(t) as IProcessor );
);
And you will have met your goal of not having to maintain a hardcoded list anywhere.

You can rewrite private IProcessor GetProcessor(string name) method using a little mix of reflection and LINQ like this:
private IProcessor GetProcessor<Tinterface>(string name) where Tinterface : IProcessor
{
var type = typeof(Tinterface).Assembly.GetTypes()
.First(x => x.FullName.Contains("name"));
return (Tinterface)Activator.CreateInstance(type);
}
Usage:
static void Main(string[] args)
{
var processor = GetProcessor<IProcessor>(args[0]);
processor.Process();
}
This route saves you the stress of typing the fully qualified name of the class

You can try iterate over all exported types in specific assembly:
using System;
using System.Linq;
using System.Reflection;
namespace ConsoleApp
{
public class Program
{
public static void Main (string[] args)
{
Assembly assembly = typeof (Program).Assembly; // use current assembly...
var types = assembly.GetExportedTypes() // public types only
.Where (type => type.GetInterfaces().Contains (typeof (IProcessor))) // interface must be implemented
.Where (type => type.Name.EndsWith ("Processor")) // and maybe use some naming convention?
.ToList();
//string name = args[0];
string name = "Parrot";
Type parrotType = types.Where (x => x.Name.StartsWith (name)).FirstOrDefault();
if (parrotType != null)
{
// it will work only when we implement parameterless constructor for this type
IProcessor parrotInstance = (IProcessor) Activator.CreateInstance (parrotType);
parrotInstance.Process();
}
}
}
public interface IProcessor
{
void Process();
}
public class SnakeProcessor : IProcessor
{
public void Process()
{
}
}
public class ParrotProcessor : IProcessor
{
public void Process()
{
Console.WriteLine ("Parrot Process");
}
}
}

I will add to the answers that suggest using reflection : EX: IProcessor parrotInstance = (IProcessor) Activator.CreateInstance(parrotType); is to make this part of code in a separate Factory class for Processor this way you can reuse the factory class in other places in your code, also even if you decide to keep the switch statement, the changes on the factory class will only affect it without affecting any dependent code.
public interface IProcessorFactory
{
IProcessor GetProcessor(string processorTypeName);
}
Good read:
SOLID Design Principles

Ninject Constructor argument check parameter existence

I was wondering if there is anyway, how to do a parameter existence check with Ninject?
What I am referring to: let's have a theoretical class and an interface:
public interface IFileExistenceCheck
{
bool FileExist();
}
public class FileExistenceChecker : IFileExistenceCheck
{
private readonly string filePath;
private readonly IFileSystem fileSystem;
public FileExistenceChecker(IFileSystem fileSystem, string filePath)
{
this.fileSystem = fileSystem;
this.filePath = filePath;
}
public bool FileExist()
{
return this.fileSystem.File.Exists(this.filePath);
}
}
Then somewhere in the code, I will be getting an instance of IFIleExistenceCheck interface via kernel like so:
public class Foo()
{
public void Bar()
{
// do something
var filePath = SomeMagicString;
var filePathArgument = new ConstructorArgument("filePath", filePath); // <- This part I do not really like
var checker = Kernel.Get<IFileExistenceCheck>(filePathArgument);
var fileExist = checker.FileExist();
// do the rest of code
}
}
This will work just fine, problem is, that it will only work as long as the name of file path argument stays the same. Let's say one day somebody will decide, that filePath is unnecessary and renames it just to path. The code itself will still compile, but it will not cause any error until somebody will actually do the call to the Bar() method.
Is there any way how to prevent this from happening?
I do not really want to expose the filePath. I still want it to be passed as an argument of a constructor. I do not want to change signature of FileCheck() to accept filePath as an argument and I do not even want to change filePath to publicly accessible field.

This is abusing the DI container as a service locator, and yet another reason why it service locator is considered to be anti-pattern.
Your contrived example would not happen if you were using the dependency injection pattern. Refactoring your example to use dependency injection, it would look like this:
public interface IFileExistanceCheck
{
bool FileExist(string filePath);
}
public class FileExistanceChecker : IFileExistanceCheck
{
private readonly IFileSystem fileSystem;
public FileExistanceChecker(IFileSystem fileSystem)
{
if (fileSystem == null)
throw new ArgumentNullException(nameof(fileSystem));
this.fileSystem = fileSystem;
}
// Pass runtime data through the method parameters!
public bool FileExist(string filePath)
{
// Prevent an empty file path from being used
if (string.IsNullOrEmpty(filePath))
throw new ArgumentNullException(nameof(filePath));
return this.fileSystem.File.Exists(filePath);
}
}
Foo Class
public class Foo
{
private readonly IFileExistanceCheck fileExistanceCheck;
public Foo(IFileExistanceCheck fileExistanceCheck)
{
if (fileExistanceCheck == null)
throw new ArgumentNullException(nameof(fileExistanceCheck));
this.fileExistanceCheck = fileExistanceCheck;
}
public void Bar()
{
// do something
var filePath = SomeMagicString;
var fileExist = fileExistanceCheck.FileExist(filePath);
// do the rest of code
}
}
At the composition root, Ninject would tie it all together and get Foo running.
class Program
{
static void Main(string[] args)
{
// Begin composition root
var kernel = new StandardKernel();
kernel.Bind<IFileSystem>().To<FileSystem>();
kernel.Bind<IFileExistanceCheck>().To<FileExistanceChecker>();
var app = kernel.Get<Foo>();
// End composition root
app.Bar();
}
}
If there is a need to check for the existence of the filePath parameter, this check can be done using a guard clause. You only need to use the dependency injection pattern, and pass the runtime data (the file path) through a method parameter.
If you want the filePath to be a configuration value that is passed through the constructor at application startup, then having a service to check for file existence seems rather pointless. In that case, you should check whether the file exists before allowing your application to run.
class Program
{
static void Main(string[] args)
{
var filePath = "SomeFileThatShouldExist.txt";
// Check configuration
if (!File.Exists(filePath))
throw new InvalidOperationException("Invalid configuration");
// Begin composition root
var kernel = new StandardKernel();
kernel.Bind<Foo>().To(new Bar(filePath));
// Register other services...
var app = kernel.Get<Foo>();
// End composition root
app.Bar();
}
}

If your parameter is known only in runtime you can inject factory and create your FileExistenceChecker with it:
public interface IFileExistenceCheckerFactory
{
IFileExistenceCheck Create(string path);
}
...
var kernel = new StandardKernel();
kernel.Bind<IFileExistenceCheck>().To<FileExistenceChecker>();
kernel.Bind<IFileSystem>().To<FileSystem>();
kernel.Bind<IFileExistenceCheckerFactory>().ToFactory(() => new TypeMatchingArgumentInheritanceInstanceProvider());
var factory = kernel.Get<IFileExistenceCheckerFactory>();
var checker = factory.Create("SomeMagicString");
var fileExist = checker.FileExist();
Then even if your parameter names don't match, TypeMatchingArgumentInheritanceInstanceProvider ensure that parameters will be matched by its type.

Can we assign TextContext.TestDeploymentDir value to a static class data member?

I am very new to CodedUI test automation framework. I came across TestContext which has the important information regarding test result outputs and directories.
Actually i have created a static Logger class which writes output data to a .txt file. Now i want to create it under TestResults folder. Everytime i am running the test method it is creating a folder followed by some timestamp. I want to create my Results.txt file in that location.
Below is the code i am using :
public static class Logger
{
string logLocation = TestContext.TestDeploymentDir + "\\Results.txt";
static Logger() {
File.Create(logLocation);
using (var fs = new FileStream(logLocation, FileMode.Truncate))
{
}
}
public static void ResultLog(int testcasenum,String Expected,String Actual, String textResult)
{
FileInfo outtxt = new FileInfo(logLocation);
StreamWriter logline = outtxt.AppendText();
logline.WriteLine("Test Case : " + testcasenum);
logline.WriteLine("{0},{1},{2}", "Expected - "+Expected, "Actual - "+Actual, "Result - "+textResult);
// flush and close file.
logline.Flush(); logline.Close();
}
}
Now i am getting a compile time error saying A field initializer cannot reference the non-static field, method, or property TestContext.TestDeploymentDir. Not sure how to resolve this error or whether it is possible or not ?

You're going to need to mark logLocation as static since it is contained in a static class. It's kind of silly but all members of a static class do also need to be marked static. I believe this is to prevent confusion when reading larger classes where you cannot see the class declaration. Next your current error message also says TestContext.TestDeploymentDir is not marked static and you'll need to modify that as well if possible. If not you'll need to implement a singleton pattern to provide a static copy of an instance of that class. Depending on the way that class works it may or may not be possible.

Finally figured out a way to get the out path of Coded UI framework. Below is the code i have written :
public static class Logger
{
static string uripath = System.IO.Path.GetDirectoryName(System.Reflection.Assembly.GetExecutingAssembly().GetName().CodeBase) + "\\Results.txt";
public static string logLocation = new Uri(uripath).LocalPath;
static Logger() {
using (File.Create(logLocation))
{ }
using (var fs = new FileStream(logLocation, FileMode.Truncate)){}
}
public static void ResultLog(int testcasenum,String Expected,String Actual, String textResult)
{
FileInfo outtxt = new FileInfo(logLocation);
StreamWriter logline = outtxt.AppendText();
logline.WriteLine("Test Case : " + testcasenum);
logline.WriteLine("{0},{1},{2}", "Expected - "+Expected, "Actual - "+Actual, "Result - "+textResult);
// flush and close file.
logline.Flush(); logline.Close();
}
}
uripath will contain the same path as that of TestContext.TestDeploymentDir. Now Results.txt will come as an attachment in Test Explorer and we can see the output.

MEF Ignores CreationPolicy

I want to create an delegate based export for an interface which is called upon every compose call to return every consumer a new instance. But apparently I do get always the same instance back. Is this a limitation of MEF (I am using .NET 4.0)?
Here is the sample code how I tried to create fresh instances for every compose call:
using System;
using System.Collections.Generic;
using System.ComponentModel.Composition;
using System.ComponentModel.Composition.Hosting;
using System.ComponentModel.Composition.Primitives;
namespace TestApp
{
class Program
{
[Import(RequiredCreationPolicy = CreationPolicy.NonShared)]
ITest Instance { get; set; }
static void Main(string[] args)
{
CompositionContainer container = new CompositionContainer();
CompositionBatch batch = new CompositionBatch();
AddExportedValue<ITest>(batch, () =>
{
Console.WriteLine("Create new");
return new Haha();
}, CreationPolicy.NonShared);
container.Compose(batch);
Program p1 = new Program();
container.SatisfyImportsOnce(p1);
// Why do I see only one "Create new" print although CreationPolicy on import and export level is NonShared?
container.SatisfyImportsOnce(p1);
}
interface ITest
{}
class Haha : ITest
{}
static ComposablePart AddExportedValue<iT>(CompositionBatch batch, Func<iT> factory, CreationPolicy policy)
{
string contractNameAndTypeIdentity = AttributedModelServices.GetContractName(typeof(iT));
IDictionary<string, object> metadata = new Dictionary<string, object>();
metadata.Add(CompositionConstants.ExportTypeIdentityMetadataName, contractNameAndTypeIdentity);
metadata.Add(CompositionConstants.PartCreationPolicyMetadataName, policy); // <--- the policy seems to be ignored by MEF although incompatible policies are errored out with an exception.
return batch.AddExport(new Export(contractNameAndTypeIdentity, metadata, () => factory()));
}
}
}
Expected Output:
Create new
Create new
Actual Output
Create new

you can use ExportFactory with .NET4.0 too. Glenn Block posted a version a while ago. i use it in my projects too.