I'm trying to wrap my head around unit testing, and I've encountered a behavior that I'm unsure of:
"Can Backup Inventory"
Basically, the "Inventory" table is copied to the "InventoryHistory" table, and given a time-stamp of when the backup occurred ("HistoryDate").
Here's the code for backing-up inventory:
DateTime historyDate = DateTime.Now;
MyDataContext db = new MyDataContext();
db.GetTable<InventoryHistory>().InsertAllOnSubmit(
db.GetTable<Inventory>()
.Select(i => new InventoryHistory
{
ID = i.ID,
ItemName = i.ItemName,
/* etc, etc, etc */
HistoryDate = historyDate
})
);
My questions are:
Should/Can this behavior be broken down into smaller unit-testable parts?
Since I am testing against a dedicated test database, should I be using a mocking tool and following the abstract factory pattern for any "repositories"?
The question I would ask is that is this really a unit test? A unit test would consider mocked Table<TEntity> instances, because we're not concerned with the actual data, rather that the mechanism of creating the items is correct.
In your snippet above, it seems that you are unit testing the Linq methods themselves, not any specific code you have written yourself.
As for your last question, one of the fundamental mistakes made with mocking is the assumption of what to test when mocking. Typically you would be mocking a something consumed by the type you want to test. E.g.:
public ICalculatorService
{
int Add(int a, int b);
}
[Test]
public void CannAdd()
{
var mock = Mock<ICalculatorService();
mock.Setup(m => m.Add(It.IsAny<int>(), It.IsAny<int>()))
.Returns(100);
var service = mock.Object;
Assert(service.Add(1, 2) == 100); // Incorrect
}
The above is a pointless test, because I am testing that it is returning exactly what I have told it to. I'm not testing the Moq framework here, I need to test my code, so I would need to be testing the consumer:
public class Calculator
{
private readonly ICalculatorService _service;
public Calculator(ICalculatorService service)
{
_service = service;
}
public int Add(int a, int b)
{
return _service.Add(a, b);
}
}
[Test]
public void CannAdd()
{
var mock = Mock<ICalculatorService();
mock.Setup(m => m.Add(It.IsAny<int>(), It.IsAny<int>()))
.Returns(100);
var calculator = new Calculator(mock.Object);
Assert(calculator.Add(1, 2) == 100); // Correct
}
That's more like it (although a simplistic example). I am now testing the Calculator consumer itself, not the consumable. In your example, even if you were mocking your DataContext to return dummy instances of Table<TEntity>, what real benefits do you get?
Realistically you'd probably create a repository, e.g. an IInventoryRepository, and create a consumer of that repository (could be a domain model, a controller, etc). Then through testing, you'd mock that repository, and test your consumer.
This looks like a fairly atomic operation to me, not much opportunity for breaking it apart.
Unit testing does not hit the database- that's integration testing. If you want a good unit test for this, you would test for behavior- in this case, that the history is backed up when it's supposed to be.
By way of full disclosure, I'm only just starting to learn EF and LINQ and the best way to test them, so you may get some more useful information regarding them in particular, so these are just general testing answers.
1.
I can't see a way that this can be further broken down to be isolated for unit testing, apart from:
ID = i.ID,
ItemName = i.ItemName,
/* etc, etc, etc */
HistoryDate = historyDate
being refactored into a seperate method to be unit tested as the only other code are LINQ calls, which MS are responsible for testing.
2.
I don't think you'd be able to introduce a seam to isolate it with the abstract repository factory pattern, since you're calling into a datacontext.
I'm not sure whether you should fake this (and since you'd be testing against it will be a mock proper - a fake that you test against, a fake that you don't test against is a stub) but since it's calling into a test server, you can make it an automated integration test since the functionality involves the interaction with the data store.
At first, method you describe looks simply and I'm not sure it needs any unit tests.
But, if you want to decompose it, you may do this:
Extract method for getting list of inventories for backup
IQueryable GetInventoryForBackup(this DataContext context)
{
return context.GetTable();
}
Extract method to convert Inventory to InventoryHistory
IEnumerable ToInventoryHistory(this IEnumerable data, DateTime historyDate)
{
return data.Select(i => new InventoryHistroy { ID = i.Id ....
}
Extract method to save sequence of InventoryHistory
void SaveHistory(IEnumerable data)
{
dataContext.InsertAllOnSubmit(data);
dataContext.SubmitChanges();
}
Now you have seemsful methods and you can easy write unit tests for.
Related
I have a service class with several methods. Service has some dependencies on repositories. I am using Moq to mock the repository. I have a problem with the proper unit testing one of the methods. I will give you an example:
public interface IRepository<T>
{
IEnumerable<T> FindAll();
IEnumerable<T> FindByQuery(Predicate<T> predicate);
//many other methods for retreiving T's
}
public class MyService
{
private readonly IRepository<Category> _repo;
public MyService(IRepository<Category> repo)
{
_repo = repo;
}
public List<Category> FindActiveCategories()
{
return _repo.FindAll().Where(x => x.Active).ToList();
}
}
Now, I wrote a unit test:
public FindActiveCategories_WhenCalled_ShouldReturnActiveCategories() {
var moq = new Mock<IRepository<Category>>();
var list = new List<Category>
{
new Category {Active = true},
new Category {Active = false}
};
moq.Setup(x => x.FindAll()).Returns(list);
var service = new MyService(moq.Object);
var result = service.FindActiveCategories();
Assert.IsTrue(result.All(x=>x.Active));
}
And the test of course passed. But than I realized that I retreived all the Categories in my service method using FindAll - it was an obvious thing to correct, because I didn't want to load several thousands of categories to memory just to pull out only few of them. So I changed the implementation of FindActiveCategories method to this:
public List<Category> FindActiveCategories()
{
return _repo.FindByQuery(x => x.Active).ToList();
}
And my test failed this time. The problems is obvious - the test depended on the implementation details. I knew that the FindActiveCategories method uses FindAll method of the repository, so I wrote a setup for this method. After changing the implementation I have to change the implementation of the test method - this seems to be a problem. Of course I could've setup all the Find... methods but there are plenty of them in the repository and one can choose many of them, this also doesn't seem right approach for me. Not to mention TDD - if I was trying to write the test first, I wouldn't know what and how to mock the repository interface. My question is: what is a correct way to handle this kind of dependencies to be able to write implementation independent unit tests.
Despite the title of this question, the actual question here seems to be "should I need to change my test if my code implementation changes?"
The answer to that is that if the implementation is entirely contained within your code under test then 'no'. For example, if I have a method to multiply two values and I implement it the obvious way, I can write tests to prove that it works. Now if I change the implementation to do the calculation using a for loop and accumulating a total within the loop, all of my tests should pass with no changes.
The problem is that most of the code we write isn't like that: it depends on other things. If the code under test depends on other things we have two choices: do an integration test, or mock the dependency.
The integration test supplies the class under test with the real dependencies that it would be using when actually in use. This is the most valuable testing, since it is completely realistic. The answer here would also be 'no need to change the test if you change the implementation'. However, this is often impractical, since it exponentially increases the cost of writing and maintaining the tests.
Mocking requires you to specify how the dependency should behave, so by definition, your test must know what the code under test is going to use, and how. Therefore if you change the implementation, you should reasonably expect to have to change the test, so the answer would be 'yes'.
However, consider this point. The parts of your test which do not relate to mocking should not need to change. You aren't using the Arrange Act Assert pattern (which can help make tests more readable, particularly when mocking); but the Act and Assert parts, which would be the last two lines of your test, should not need to change. Maybe that will allow you to believe you're still doing TDD.
But don't lose sleep over it: there are other things which would benefit from your attention more. For example, change the implementation of your method to...
public List<Category> FindActiveCategories()
{
return new List<Category>();
}
... then the test will pass, even though the code won't do what you want (because the All in the assert returns true for an empty list).
Hope this was useful.
The following will work for the change made above.
[TestClass]
public class MyServiceShould {
[TestMethod]
public void FindActiveCategories_WhenCalled_ShouldReturnActiveCategories() {
//Arrange
var moq = new Mock<IRepository<Category>>();
var list = new List<Category> {
new Category {Active = true},
new Category {Active = false}
};
moq
.Setup(x => x.FindByQuery(It.IsAny<Predicate<Category>>()))
.Returns((Predicate<Category> predicate) => list.Where(x => predicate(x)));
var service = new MyService(moq.Object);
//Act
var result = service.FindActiveCategories();
//Assert
Assert.IsTrue(result.All(x => x.Active));
}
}
The mock takes the passed predicate and applies it to the fake collection in order to allow the test to be exercised to completion.
Reference Moq Quickstart to get a better understanding of how to use the mocking framework.
Lets say that I have the following Unit Test for Entity Framework 6 using Moq:
public void Save_Employee_via_context()
{
var MockContext = new Mock<DcmDataContext>();
var MockSet = new Mock<DbSet<Employee>>();
MockContext.Setup(m => m.Employees).Returns(MockSet.Object);
var service = new GeneralService(MockContext.Object);
//Test valid inputs
for (int i = 0; i < TestData.ValidEmployees.Count; i++)
{
service.AddEmployee(TestData.ValidEmployees[i]);
//veryfy that it was properly inserted
Assert.AreEqual(TestData.ValidEmployees[i],MockSet.Object.Find(TestData.ValidEmployees[i].EmployeeID));
}
//Ensure that the proper methods were called each time. It is implied that this happened if the above
//Assert methods passed, but double checking never killed anybody
MockSet.Verify(m => m.Add(It.IsAny<Employee>()), Times.Exactly(TestData.ValidEmployees.Count));
MockContext.Verify(m => m.SaveChanges(), Times.Exactly(TestData.ValidEmployees.Count));
//Test invalid Inputs
MockSet = new Mock<DbSet<Employee>>();
//InvalidEmployees is a Dictionary<Employee,Type>, where Type is the type of exeption that should eb thrown if
//You attempt to add that Employee
foreach (var pair in TestData.InvalidEmployees)
{
try
{
service.AddEmployee(pair.Key);
//AddEmployee *SHOULD* throw an exception here here.. if not...
Assert.Fail();
}
catch (Exception ex)
{
//Was it the exception that I was expecting to catch?
Assert.Equals(ex.GetType(), pair.Value);
}
}
//ensure that nothing new has been added (redundant, I know, but it doesn't hurt)
MockSet.Verify(m => m.Add(It.IsAny<Employee>()), Times.Never);
MockContext.Verify(m => m.SaveChanges(), Times.Exactly(TestData.ValidEmployees.Count));
}
TestData is a Static Class that I have that holds lists for each model type that I want to test, along with several test cases for each, with both valid and invalid inputs.
I created my test like this because my objects can be fairly large (Employee, for example, has around 15 properties), and as such there is a wide array of test cases that I want to run in order for each test to be thorough. I didn't want to copy/paste, each array of test sample data every single method that needs it, so I wanted to store it in a static container.
I feel like this poses a problem, however. For instance, one of the properties of Employee is Position. You know, what job they have. it is a required property, and an exception should be thrown if that position is either null, or doesn't already exist in the database. That means that in order for the above test to be valid, I'm going to need some mock positions to be in there as well. Oh, but each Position has a Department Attribute... so that needs to be set up too...
Do you see where I am going with this? How can I properly test my code without a full suite of test data to test it against? Well then, I suppose I'll have to write a full suite of test data. Which I did.
The problem is, where do I put it? I decided to put in all in the TestData Class.
This, however, presents a set of problems. Initialization is the biggest one, because I feel like I have to neuter my test data in order to make initialization even remotely feasible. For instance, all of my navigation properties are probably going to have to be null. How could I have my ValidEmployees each have a List<Clients>, and each Client have an assigned Employee without, once again, hard duplicating each Employee as a property of Client, and in the List<Employee> that each Position is going to have. wouldn't it be nice to have Clients = {ValidClients[0],ValidClients[1] within ValidEmployees and SalesRepresentative = ValidEmployees[0] within ValidClients?
I also feel like I need that Navigation data. will
Assert.AreEqual
(
TestData.ValidEmployees[i],
MockSet.Object.Find(TestData.ValidEmployees[i].EmployeeID
)
still return true if ValidEmployees doesn't have navigationData in it? Does this mean I should find another way of ensuring state?
Anyway, these are the problems that I am running into. Am I just setting up my Unit tests completely wrong? How else am I supposed to get robust, independent, DRY and accurate unit tests? What am I missing here?
Any help is appreciated, even if it means starting from scratch with a different mindset. This is my first project where I am taking testing very seriously, but I feel like it isn't going so well. As such, sorry for the wall of text. Sometimes I feel like i'm not asking the right question to get where I want to go.
To answer your second part of the question (about test data). I would not use a test data class for my tests, this will make the tests fragile and may introduce subtle bugs as a change to the test data class may affect numerous unrelated tests in different test classes, google Object Mother Anti-Pattern.
I went down the Object Mother route before and ended up with a whole project containing all my test data. When I needed a new variation of the test data, I kept altering/adding to the object mother. Needless to say, the project became bloated and unmaintainable very quickly. Also, the fact that some unit tests started failing because of these changes (as there is a dependency on this shared data), and the extra time spent to fix them, made it a real annoyance. Hence, I decided that a better approach is to let unit test classes own the data they use (in other words, the test data is contained within the Test Fixture). To achieve this, I introduced a test data builder project but this meant that I have another project to maintain and change (when needed) whenever I write a unit test. Honestly, I'd rather concentrate on the unit tests themselves and not worry about the plumbing and that's why I started using a test data generator. I'm using NBuilder but I've heard very good things about AutoFixture as well. These will allow you to build your test data, concentrate on the parts that are relevant to the behaviour you're testing and let the builder generate random data for the ones that are not (you can control/override the random generators). I'm of the opinion that in order to improve the unit test readability, you should only show (or emphasise) the data that affects the behaviour that you're testing rather than bloat your unit test with irrelevant information.
Example:
var validEmployees = Builder<Employees>.CreateListOfSize(10)
.All()
.With(x => x.IsActive = true)
.And(x => x.LeaveDate = null)
.Build();
Looking at your tests, it appears that your service.AddEmployee does too much :). You can split the validation logic, etc.
Consider test like this (to lead your design). This uses a FakeDbSet:
[Test]
public void Should_add_any_valid_employees_and_save_them()
{
//arrange
var validator = new Mock<IEmployeeValidator>();
validator.Setup(v => v.Validate(It.IsAny<Employee>())).Returns(true);
// ... setup the context and the dbset
var service = new MyService(validator.Object, mockContext.Object)
var newData = new List<EmployeeDto>
{
new EmployeeDto{Id = 1},
new EmployeeDto{Id = 2}
}
// act
service.AddEmployees(newData);
// assert
mockContext.Verify(c => c.SaveChanges(), Times.Once());
Assert.True(fakeDbSet.Count == newData.Count);
CollectionAssert.AreEquivalent( newData.Select(e=>e.Id), mockData.Select(e=>e.Id));
}
[Test]
public void Should_not_add_any_invalid_employees()
{
//arrange
var validator = new Mock<IEmployeeValidator>();
validator.Setup(v => v.Validate(It.IsAny<Employee>())).Returns(false);
// ... setup the context and the dbset
var service = new MyService(validator.Object, mockContext.Object)
var newData = new List<EmployeeDto>
{
new EmployeeDto{Id = 1},
new EmployeeDto{Id = 2}
}
// act
service.AddEmployees(newData);
// assert
mockContext.Verify(c => c.SaveChanges(), Times.Never());
Assert.True(fakeDbSet.Count == 0);
CollectionAssert.IsEmpty( mockData );
}
You can throw in the mix IEmployeeDtoToEmployee mapper as well, so you abstract this part of the functionality as well.
This comes after 3 days of researching and writing code. I have EF Code First ( EF5) and a generic repository pattern built on top of it.
Now I have ICustomerRepository<Customer> : IRepository and
CustomerRepository : RepositoryBase<MyContext> , ICustomerRepository. So when I go about testing this I find that I have to write A FakeDbContext , A Fake IDbSet and then Fake the data as well and do a lot more as well. All this when I know that I am going to test Linq to Objects with my in memory data and Linq to Entities will require another suite of tests in the form of integration tests. So, either my code structure is wrong and thus writing unit tests is so difficult or there is a better way to write tests that I am unaware of or I should just have Integration Tests. I am using NUnit and MOQ.
Edit : What is it that I am trying to test ?
I am trying to check methods like GetCustomersByType , Add , GetOrderPlacedByCustomer . Trying to see if the logic inside those methods is correct. This what unit test are for , I guess.
I think you will get a lot more if you create a test initialize method that will setup all the data before each test,ie.black box testing. In the end, you will know that repository layer is doing it's job properly on real database, not a mocked one.
For example:
public static void Init()
{
_unityContainer = new UnityContainer();
_unityContainer.LoadConfiguration();
_persistenceFactory = _unityContainer.Resolve<IPersistenceFactory>();
_unitOfWork = _persistenceFactory.GetUnitOfWork();
_usersRepository = _persistenceFactory.GetUsersRepository();
_usersRepository.RemoveAll();
_unitOfWork.Commit();
}
public static void InsertTestData()
{
User u = new User("johndoe#gmail.com", "John Doe", "johndoe");
_usersRepository.Add(u);
_unitOfWork.Commit();
}
You can use TransactionScope to simulate DB access, but not committing the actual changes to the database. Something like this:
[TestMethod]
public void AddingShouldWork()
{
using (var transaction = new TransactionScope())
{
var repository = new ICustomerRepository<Customer>();
var customer = new Customer();
customer.Name = "OEM Computers Inc.";
repository.Add(customer);
}
}
By not calling transaction.Complete() the operations are treated just like a rollback, resulting in no database insert. This is just the behaviour you want for unit (not integration) testing. You can also use Moq<Customer> to not create real entities.
I have a Lin2Sql DataContext that I am using to get all my data from a sql database however I am struggling to find a way to successfully Mock this so that I can create relevant Unit Tests.
In my data access objects that I am wanting to test I am refreshing the context each time and I am finding it difficult to find a simple suitable way to mock this.
Any help with this matter will be greatly appreciated.
Mocking the linq-to-sql context is indeed a huge task. I usually work around it by letting my unit tests run against a separate database copy, with data specially crafted to fit the unit tests. (I know it can be argued that it's no longer unit tests, but rather integration tests, but I don't care as long as I get the code tested).
To keep the database in a known state I wrap each test in a TransactionScope which is rolled back at the end of the test. That way the state of the database is never changed.
A sample test method looks like this:
[TestMethod]
public void TestRetire()
{
using (TransactionScope transaction = new TransactionScope())
{
Assert.IsTrue(Car.Retire("VLV100"));
Assert.IsFalse(Car.Retire("VLV100"));
// Deliberately not commiting transaction.
}
}
The code is from a blog post about the method I wrote some time ago: http://coding.abel.nu/2011/12/using-transactions-for-unit-tests/
Since you request a way to mock a DataContext I assume that you really want to do some unit tests and not integration tests.
Well, I will tell you how to accomplish this, but first I would like to encourage you to read the following links, they are all about writing clean testable code.
http://misko.hevery.com/code-reviewers-guide/
http://misko.hevery.com/attachments/Guide-Writing%20Testable%20Code.pdf
And check the links from this response:
https://stackoverflow.com/a/10359288/1268570
Watch the clean code talks from Misko Hevery (given to the Google people)
http://www.youtube.com/watch?v=wEhu57pih5w&feature=player_embedded
http://www.youtube.com/watch?v=RlfLCWKxHJ0&feature=player_embedded
http://www.youtube.com/watch?v=-FRm3VPhseI&feature=player_embedded
http://www.youtube.com/watch?v=4F72VULWFvc&feature=player_embedded
One thing that I used to repeat to myself and to my fellows at work, is that anyone can write a unit test, because they are silly easy to write. So a simple test is essentially all about making some comparisons and throw exceptions if the results fails, anyone can do that. Of course, there are hundreds of frameworks to help us write those tests in an elegant way. But the real deal, and the real effort shroud be put on learn how to write clean testable code
Even if you hire Misko Hevery to help you write tests, he will have a real hard time writing them if your code is not test-friendly.
Now the way to mock a DataContext objects is: do not do it
Instead wrap the calls using a custom interface instead:
public interface IMyDataContextCalls
{
void Save();
IEnumerable<Product> GetOrders();
}
// this will be your DataContext wrapper
// this wll act as your domain repository
public class MyDataContextCalls : IMyDataContextCalls
{
public MyDataContextCalls(DataClasses1DataContext context)
{
this.Context = context;
}
public void Save()
{
this.Context.SubmitChanges();
}
public IEnumerable<Product> GetOrders()
{
// place here your query logic
return this.Context.Products.AsEnumerable();
}
private DataClasses1DataContext Context { get; set; }
}
// this will be your domain object
// this object will call your repository wrapping the DataContext
public class MyCommand
{
private IMyDataContextCalls myDataContext;
public MyCommand(IMyDataContextCalls myDataContext)
{
this.myDataContext = myDataContext;
}
public bool myDomainRule = true;
// assume this will be the SUT (Subject Under Test)
public void Save()
{
// some business logic
// this logic will be tested
if (this.myDomainRule == true)
{
this.myDataContext.Save();
}
else
{
// handle your domain validation errors
throw new InvalidOperationException();
}
}
}
[TestClass]
public class MyTestClass
{
[TestMethod]
public void MyTestMethod()
{
// in this test your mission is to test the logic inside the
// MyCommand.Save method
// create the mock, you could use a framework to auto mock it
// or create one manually
// manual example:
var m = new MyCommand(new MyFakeDataContextFake());
m.Invoking(x => x.Save())
//add here more asserts, maybe asserting that the internal
// state of your domain object was changed
// your focus is to test the logic of the domain object
.ShouldNotThrow();
//auto mock example:
var fix = new Fixture().Customize(new AutoMoqCustomization());
var sut = fix.CreateAnonymous<MyCommand>();
sut.myDomainRule = false;
sut.Invoking(x => x.Save())
.ShouldThrow<InvalidOperationException>();
}
public class MyFakeDataContextFake : IMyDataContextCalls
{
public void Save()
{
// do nothing, since you do not care in the logic of this method,
// remember your goal is to test the domain object logic
}
public IEnumerable<Product> GetOrders()
{
// we do not care on this right now because we are testing only the save method
throw new NotImplementedException();
}
}
}
Notes:
When you declare your IMyDataContextCalls interface you are actually abstracting the use of a DataContext, therefore this interface should contain only POCO objects (most of the time), if you follow this approach your interfaces will be decoupled from any undesired dependency.
In the specific MyDataContextCalls implementation, you are explicitly using a DataClasses1DataContext context, but you are free to change the implementation at any time and that won't affect your external code, and that's because you are always working with the IMyDataContextCalls interface instead. So at any time you could change for example this implementation for another one using the wonderful NHibernate =) or the poor ef or a mock one
At last, but not least. please double check my code, and you will notice that there are no new operators in the domain objects. This is a rule of dumb when writing test friendly code: decouple the responsibility of creating objects outside of your domain objects
I personally use three frameworks on every project and on every test I write, I really recommend them:
AutoFixture
Moq
FluentAssertions
For example, in the code above, I showed you how to write a manual fake for your repository, but that clearly is something we do not want to do in a real project, imagine the number of objects you would have to code in order to write your tests.
Instead use the power of AutoFixture combined with Moq:
This line: var m = new MyCommand(new MyFakeDataContextFake());
Will become:
var fixture = new Fixture().Customize(new AutoMoqCustomization());
var sut = fixture.CreateAnonymous<MyCommand>();
And that's it, this code will automatically create mocks for all the objects needed in the constructor of MyCommand.
In short, you don't mock DataContext. You extract interface from it and mock that interface using some collections for entity sets, and then verify contents of those collections.
I use NUnit for my unit-testing. In my current project, I have a problem in which almost all of the functions I want to test are connected to the database. Meanwhile, the database is bounded when the application is started.
I am so confused now, I have read regarding mock unit-testing, but don't know exactly how to handle this problem. Any solution for me here?
To make things harder, this database is static, not as parameter of my method... This makes me so confused
You might want to review the architecture of your application. Make sure the database layer is loosely coupled, for example by using interfaces. This will make it possible to write stubs or mocks for your database layer.
The normal solution to this is to keep your data layer in a separate class that implements a well-known interface. For instance:
public interface IDataLayer
{
IEnumerable<Customer> GetAllCustomers();
Order GetOrderById(int id);
}
You will implement the interface as normal for your actual data access
public class SqlServerDataLayer : IDataLayer
{
// implementation
}
But in your tests, you can now use a mocking framework like Moq or RhinoMocks to set up a mock data layer that returns test data. This ensures you are only testing how your classes use the data, which is ideal.
[Test]
public void TestGettingCustomersRefreshesViewModel()
{
//arrange
var mockDb = new Mock<IDataLayer>();
mockDb.Setup(db => db.GetAllCustomers()).Returns(new List<Customer>());
underTest.DataRepository = mockDb.Object;
//act
underTest.GetCustomerCommand.Execute();
//assert
Assert.That(underTest.CustomerList != null);
}