Develop Reference

How can I Mock a File Upload in c#?

I have written a code for uploading a file to a cloud storage. That code consist of a post method which takes a file in the format : multipart/form-data and uploads it to cloud. So how can I write a test case for the same? To be specific, how to mock that post file.
The format used is formfile
The code is in asp.net core 3.1 using c#.

i suggest the use of abstraction here , you should create an interface like Below -
Public Interface IFileSystem{
bool uploadFile(FileStrem fileContent);
}
and then write your cloud specific implementation in a derivation from above class and
in your buisness logic use that implementation , so that when you write tests for buisness logic you can mock the FileSystem.

In the companies where I worked, 'Mocking' has never really seen too well.
Usually writing a test implementation works better:
public interface IUploader
{
IResult Upload(string filePath);
}
public sealed class FileUploader
{
IResult Upload(string filePath) { ... } // method is implemented as expected
}
public sealed class TestUploader //this is placed in a specific folder for test implementations
{
public IResult ExpectedResult { get; set; } = Result.Success();
IResult Upload(string filePath) => ExpectedResult;
}
To connect it with your class check the Humble Object Design Pattern. It explains how to extract testable logic from apparently untestable classes.
void UploadToCloud(string filePath)
{
...
Uploader.Upload(filePath); // real implementation in production code, test implementation during unit testing.
...
}
I'd prefer going this way for multiple reasons:
A change in the production code forces you to change the test implementation as well. With a Mock you would risk not to notice that your tests became obsolete.
A test implementation gives you more freedom (i.e. you can pass the test result to the test implementation in the initialization part of the test, to check edge cases).
It is cleaner than mocks and other developers can understand better what is going on. The tidier the code, the easier it is to keep it clean.
You still have some constraints given from the interface. Sometimes the Mock classes just become huge monsters that do not look like the original class anymore.
NOTE: If you want to test the receiving part, you can use the same strategy. Your test implementation will contain the expected content of the file, to test the cloud response.

BDD naming for several methods

BDD naming approach works perfectly when there's one method in a class that you're testing. Let's assume we have a Connector class which has Connect method:
Should_change_status_to_Connected_if_Disconnected
Beautiful, right? But I feel confused when I have to name tests when there're several methods in a class (let's assume we added Disconnect method to our class).
I see two possible solutions. The first one is to add a prefix with a method name like:
Should_change_status_to_Connected_if_Disconnected_when_Connect_was_called
Another approach is to introduce nested test classes for each method you're testing.
public class ConnectorTests
{
public class ConnectTests
{
public void Should_change_status_to_Connected_if_Disconnected()
{
...
}
}
public class DisconnectTests
{
public void Should_change_status_to_Disconnected_if_Connected()
{
...
}
}
}
Honestly both approaches feel a little bit off (may be just because I'm not used to it). What's the recommended way to go?

I've written dosens tests using different naming styles. Essentially, such test methods is hard to read due to long names, they exceed limit of symbols per line, often underscored names of methods go against naming conventions. Difficulties begin when you want to add "And" conditions or preconditions to your BDD scenarios, like "When Connector is initialized Should change status to Connected if Disconnected AND network is available AND argument1 is... AND argument2 is...". So you have to group your test cases in many classes, sub-folders etc. It increases time of development and support.
Alternative way in C# is writing tests like with JavaScript testing frameworks: Jasmine, Jest etc. For unit tests for classes and methods, I'd use Arrange/Act/Assert style, and BDD style for Feature/Story scenarios, but both styles can be used. In C# I use my Heleonix.Testing.NUnit library and write tests in AAA or BDD (GWT) styles:
using NUnit.Framework;
using Heleonix.Testing.NUnit.Aaa;
using static Heleonix.Testing.NUnit.Aaa.AaaSpec;
[ComponentTest(Type = typeof(Connector))]
public static class ConnectorTests
{
[MemberTest(Name = nameof(Connector.Connect))]
public static void Connect()
{
Connector connector = null;
Arrange(() =>
{
connector = new Connector();
});
When("the Connect is called", () =>
{
Act(() =>
{
connector.Connect(options);
});
And("the Connector is disconnected", () =>
{
Arrange(() =>
{
connector.Disconnect();
});
});
Should("change the status to Disconnected", () =>
{
Assert.That(connector.Disconnected, Is.True);
});
});
}
}
For me important is that in few months later I can open such tests and clearly recall what was written there, and don't sit hours to understand what/how it tests.

In my case, first, I try to separate classes depending pre and post conditions, so I can group some behaviors and keep together the related things. For example, In your case, one precondition could be "Disconnected", so, you can prepare the "disconnected environment" using attributes like ClassInitialize, TestInitialize, TestCleanup, ClassCleanup, etc. (here some examples in MSDN)
And please, as the other developers has recommended, don't forget the naming conventions.
Hope this help, greetings.

Since test cases are totally independent of each other you must to use a static class to initialize those values, connections, etc that you will use for your test later. If you want to use individuals values and initiators yo must to declare them in your classes individually. I use for this nunit framework.
And by the way, you are in c#, use the name convention of .net developers...

Splitting test classes into partial classes?

I'm looking for a good way to organize my unit tests in a .NET project. Right now, I have one TestClass per application class, with multiple tests for each method. Although I am using TestCategory to categorize each TestMethod by the application class method it tests, finding my test methods is becoming ungainly.
I'm considering splitting my test classes into partial classes - one partial class per application class method. This means that I can have multiple TestMethod in one dedicated file per method, without having to hunt through a large file to find them.
Are there any pitfalls to this approach? Are there better ways of handling large test classes in .NET and Visual Studio?
Edit: I am using IoC (we're using Castle.Windsor for DI outside of the tests) and we're using Moq for mocking capabilities. Tests are initialized with TestInitialize.

Take a look at my answer C# ASP.NET MVC Controller unit test.
The gist of it is:
a static class that wraps all the tests for a given
system under test.
a test class for each test scenario you are
running that inherits from a base class
The other nice about this setup is that it gives you a nice tree of tests, if you are using the resharper unit test session to be able to easily find your test.
As for the first answer, you should not be using a DI framework in your tests. All external dependencies should be mocked/faked so that you are only testing the system under test.
And for using partial classes. See Are C#'s partial classes bad design?
I agree with Carra, using partial classes just to split a long class is considered bad design. If your class so large, maybe it needs to be broken up.

I would keep your tests simple and concise. Separating your tests could be beneficial but where do you Initialize your test code? Are you using Inversion of Control to do work that the other tests should have already done? If so then you might want to look at [TestInitialize] and start organizing your dependencies.
Here is what I mean for centralizing TestInit
[TestClass]
public class UnitTestWebsiteBuilderPattern
{
private IHtmlInputService _htmlInputService;
private IHtmlControlService _htmlControlService;
private IHtmlMenuControlService _htmlMenuControlService;
private IHtmlConditionalInputService _htmlConditionalInputService;
private IHtmlPanelService _htmlPanelService;
private IHelpIconService _helpIconService;
private IHtmlModalService _htmlModalService;
[TestInitialize]
public void Init()
{
_helpIconService = new HtmlHelpIconService();
_htmlInputService = new HtmlInputService(_helpIconService);
_htmlPanelService = new HtmlPanelService(_htmlInputService);
_htmlModalService = new HtmlModalService(_htmlPanelService);
_htmlControlService = new HtmlControlService(_htmlPanelService);
_htmlMenuControlService = new HtmlMenuControlService();
_htmlConditionalInputService = new HtmlConditionalInputService();
}

How to test methods where DBContext is created?

I don't have a lot of experience with unit testing. For example I have simple method in the application:
public void GetName()
{
UserRights rights = new UserRights(new DatabaseContext());
string test = rights.LookupNameByID("12345");
Console.WriteLine(test);
}
In this case I'm able to test all methods of UserRights class by passing mocked DatabaseContext, but how can I test GetName() method? What is the best practice? Where DatabaseContext should be created?

If you want to test the GetName method in a properly isolated way (i.e. a Unit Test) then you can't use new to create the UserRights instance in the method itself; because a test is really just another client of the code, therefore it can't (and shouldn't) know anything about how GetName works internally
So what this means is that for a proper Unit Test you must be able to replace all dependencies of a method with ones that the client fully controls - in the case, the code in the Unit Test is the client.
In your posted code, the client code has no control at all over UserRights nor DatabaseContext, so this is the first thing that has to change.
You need to rework your code so that the UserRights implementation can be supplied by the client. In fact once that's done, the problem about where DatabaseContext comes from is actually irrelevant for the Unit test because it doesn't care about how UserRights itself performs its tasks!
There are a number of ways of doing this; you can use Mocks or Stubs, you can use Constructor or Method injection, you could use a UserRights factory. Here is an example of using very simple stubs which IMHO is the best way to start and avoids having to learn a Mocking framework -- I personally would use Mocks for this but that's cos I am lazy :)
(code below assumes the class containing GetName is called "UserService", and uses xUnit framework; but MSTest will work just fine too)
Let's suppose you have control over the code of UserService so you can make the LookupNameByID method virtual (if you can't, then you may have to go the route if interfaces and mocks)
public class UserRights
{
public virtual LookupNameByID(string id)
{
//does whatever a UserRights does.
}
}
public class UserService
{
readonly UserRights _rights;
public UserService(UserRights rights)
{
_rights=rights; //null guard omitted for brevity
}
public string GetName(string id)
{
return _rights.LookupNameByID(id);
}
}
now in your unit test code suppose you create a sub-class of UserRights like this:
public class ExplodingUserRights: UserRights
{
public override string LookupNameByID(string id)
{
throw new Exception("BOOM!");
}
}
Now you can write a test to see how GetName reacts when something bad happens:
[Fact]
public void LookupNameByID_WhenUserRightsThrowsException_DoesNotReThrow()
{
//this test will fail if an exception is thrown, thus proving that GetName doesn't handle exceptions correctly.
var sut = new UserService(new ExplodingUserRights()); <-Look, no DatabaseContext!
sut.GetName("12345");
}
and one for when good things happen:
public class HappyUserRights: UserRights
{
public override string LookupNameByID(string id)
{
return "yay!";
}
}
[Fact]
public void LookupNameByID_ReturnsResultOfUserRightsCall()
{
//this test will fail if an exception is thrown, thus proving that GetName doesn't handle exceptions correctly.
var sut = new UserService(new HappyUserRights());
var actual = sut.GetName("12345");
Assert.Equal("yay!",actual);
}
and so on. Note that we never went anywhere near DatabaseContext, because that's a problem you only have to solve when you unit test the UserRights class itself. (and at that point I would probably recommend using Jeroen's advice from his linked article,and do an integration test, unless setup of a database for each test is something you can't or won't do, in which case you need to use interfaces and mocks)
Hope that helps.

Separating your codes reliance on DB Context is something you will want to investigate, this can be accomplished using the Repository pattern. Since you're passing the DB Context into your objects constructor, in this case UserRights, you can pretty easily change your code to take in an Interface (or simply add an overloaded contructor to the class that accepts an interface, then call that in your unit tests, preserving any existing code). There are lots of ways to get this done, a quick Google search yielded the following article:
http://romiller.com/2012/02/14/testing-with-a-fake-dbcontext/
http://www.codeproject.com/Articles/207820/The-Repository-Pattern-with-EF-code-first-Dependen
Once your class can accept an interface rather than (or as an alternative to) the strongly typed DB Context object you can use a Mock framework to assist with testing. Take a look at Moq for examples on how to use these in your unit tests https://github.com/Moq/moq4/wiki/Quickstart
Be Aware: Moq can become difficult to work with when your tests require data that is related via foreign keys, the syntax can be complicated to get your head around. One thing to watch out for is the temptation to make changes to your code just to make a unit test easier to set up, while there may be value in making this change it also may indicate that you need to re-think your unit test rather than violate your applications architecture and/or design patterns

Is this a poor design?

I'm trying my hand at behavior driven development and I'm finding myself second guessing my design as I'm writing it. This is my first greenfield project and it may just be my lack of experience. Anyway, here's a simple spec for the class(s) I'm writing. It's written in NUnit in a BDD style instead of using a dedicated behavior driven framework. This is because the project targets .NET 2.0 and all of the BDD frameworks seem to have embraced .NET 3.5.
[TestFixture]
public class WhenUserAddsAccount
{
private DynamicMock _mockMainView;
private IMainView _mainView;
private DynamicMock _mockAccountService;
private IAccountService _accountService;
private DynamicMock _mockAccount;
private IAccount _account;
[SetUp]
public void Setup()
{
_mockMainView = new DynamicMock(typeof(IMainView));
_mainView = (IMainView) _mockMainView.MockInstance;
_mockAccountService = new DynamicMock(typeof(IAccountService));
_accountService = (IAccountService) _mockAccountService.MockInstance;
_mockAccount = new DynamicMock(typeof(IAccount));
_account = (IAccount)_mockAccount.MockInstance;
}
[Test]
public void ShouldCreateNewAccount()
{
_mockAccountService.ExpectAndReturn("Create", _account);
MainPresenter mainPresenter = new MainPresenter(_mainView, _accountService);
mainPresenter.AddAccount();
_mockAccountService.Verify();
}
}
None of the interfaces used by MainPresenter have any real implementations yet. AccountService will be responsible for creating new accounts. There can be multiple implementations of IAccount defined as separate plugins. At runtime, if there is more than one then the user will be prompted to choose which account type to create. Otherwise AccountService will simply create an account.
One of the things that has me uneasy is how many mocks are required just to write a single spec/test. Is this just a side effect of using BDD or am I going about this thing the wrong way?
[Update]
Here's the current implementation of MainPresenter.AddAccount
public void AddAccount()
{
IAccount account;
if (AccountService.AccountTypes.Count == 1)
{
account = AccountService.Create();
}
_view.Accounts.Add(account);
}
Any tips, suggestions or alternatives welcome.

When doing top to down development it's quite common to find yourself using a lot of mocks. The pieces you need aren't there so naturally you need to mock them. With that said this does feel like an acceptance level test. In my experience BDD or Context/Specification starts to get a bit weird at the unit test level. At the unit test level I'd probably be doing something more along the lines of...
when_adding_an_account
should_use_account_service_to_create_new_account
should_update_screen_with_new_account_details
You may want to reconsider your usage of an interface for IAccount. I personally stick
with keeping interfaces for services over domain entities. But that's more of a personal preference.
A few other small suggestions...
You may want to consider using a Mocking framework such as Rhino Mocks (or Moq) which allow you to avoid using strings for your assertions.
_mockAccountService.Expect(mock => mock.Create())
.Return(_account);
If you are doing BDD style one common pattern I've seen is using chained classes for test setup. In your example...
public class MainPresenterSpec
{
// Protected variables for Mocks
[SetUp]
public void Setup()
{
// Setup Mocks
}
}
[TestFixture]
public class WhenUserAddsAccount : MainPresenterSpec
{
[Test]
public void ShouldCreateNewAccount()
{
}
}
Also I'd recommend changing your code to use a guard clause..
public void AddAccount()
{
if (AccountService.AccountTypes.Count != 1)
{
// Do whatever you want here. throw a message?
return;
}
IAccount account = AccountService.Create();
_view.Accounts.Add(account);
}

The test life support is a lot simpler if you use an auto mocking container such as RhinoAutoMocker (part of StructureMap) . You use the auto mocking container to create the class under test and ask it for the dependencies you need for the test(s). The container might need to inject 20 things in the constructor but if you only need to test one you only have to ask for that one.
using StructureMap.AutoMocking;
namespace Foo.Business.UnitTests
{
public class MainPresenterTests
{
public class When_asked_to_add_an_account
{
private IAccountService _accountService;
private IAccount _account;
private MainPresenter _mainPresenter;
[SetUp]
public void BeforeEachTest()
{
var mocker = new RhinoAutoMocker<MainPresenter>();
_mainPresenter = mocker.ClassUnderTest;
_accountService = mocker.Get<IAccountService>();
_account = MockRepository.GenerateStub<IAccount>();
}
[TearDown]
public void AfterEachTest()
{
_accountService.VerifyAllExpectations();
}
[Test]
public void Should_use_the_AccountService_to_create_an_account()
{
_accountService.Expect(x => x.Create()).Return(_account);
_mainPresenter.AddAccount();
}
}
}
}
Structurally I prefer to use underscores between words instead of RunningThemAllTogether as I find it easier to scan. I also create an outer class named for the class under test and multiple inner classes named for the method under test. The test methods then allow you to specify the behaviors of the method under test. When run in NUnit this gives you a context like:
Foo.Business.UnitTests.MainPresenterTest
When_asked_to_add_an_account
Should_use_the_AccountService_to_create_an_account
Should_add_the_Account_to_the_View

That seems like the correct number of mocks for a presenter with a service which is supposed to hand back an account.
This seems more like an acceptance test rather than a unit test, though - perhaps if you reduced your assertion complexity you would find a smaller set of concerns being mocked.

Yes, your design is flawed. You are using mocks :)
More seriously, I agree with the previous poster who suggests your design should be layered, so that each layer can be tested separately. I think it is wrong in principle that testing code should alter the actual production code -- unless this can be done automatically and transparently the way code can be compiled for debug or release.
It's like the Heisenberg uncertainty principle - once you have the mocks in there, your code is so altered it becomes a maintenance headache and the mocks themselves have the potential to introduce or mask bugs.
If you have clean interfaces, I have no quarrel with implementing a simple interface that simulates (or mocks) an unimplemented interface to another module. This simulation could be used in the same way mocking is, for unit testing etc.

You might want to use MockContainers in order to get rid of all the mock management, while creating the presenter. It simplifies unit tests a lot.

This is okay, but I would expect an IoC automocking container in there somewhere. The code hints at the test writer manually (explicitly) switching between mocked and real objects in tests which should not be the case because if we are talking about a unit test (with unit being just one class), it's simpler to just auto-mock all other classes and use the mocks.
What I'm trying to say is that if you have a test class that uses both mainView and mockMainView, you don't have a unit test in the strict sense of the word -- more like an integration test.

It is my opinion that if you find yourself needing mocks, your design is incorrect.
Components should be layered. You build and test components A in isolation. Then you build and test B+A. Once happy, you build layer C and test C+B+A.
In your case you shouldn't need a "_mockAccountService". If your real AccountService has been tested, then just use it. That way you know any bugs are in MainPresentor and not in the mock itself.
If your real AccountService hasn't been tested, stop. Go back and do what you need to ensure it is working correctly. Get it to the point where you can really depend on it, then you won't need the mock.