I have not been doing TDD and Unit Tests for 7 months now and I kind of forgot. I am now in shop that wants to start doing it but I am the only one there
and not exactly a guru in the matter.
I am a bit rusty and I am getting all sorts of questions and many times I cannot give a proper answer.
Typical questions I get:
-
I dont see anything wrong with
integration Testing? I told them is
slow ,you should never do it.If I
cannot test privateMethod (I know
MSTest does) what is the point in
testing? All my important methods are
private.I dont see the point of setting up an
expectation and return a result that
pleases the test?What are the typical unit tests you
should perform in each layer? Should
you test only at boundary levels?How
do I test my Stored Procedure return
the intended results?
Do you think the below tests make any sense to you?What kind of test would you generally do at each layer?Any examples with code?
I do 3 kinds of tests
1)ViewModel Tests.
2)Wcf Tests by mocking the service
3)Wcf Integratontest but mocking the Dal
Is this what you do?.Can you correct me if yoou thing this is wrong.Can you improve them?
ViewModel tests
property has changed
and methods have been called example below
//property has changed
[TestMethod]
public void Should_be_able_to_test_that_customer_description_propertyChanged_was_raised()
{
//act
var customerResponse=new CustomerResponse{Description = "Test"};
var customerViewModel = new CustomerViewModel(customerResponse);
var eventWasRaised = false;
customerViewModel.PropertyChanged += (sender, e) => eventWasRaised = e.PropertyName == "Description";
customerViewModel.Description = "DescriptionTest";
Assert.IsTrue(eventWasRaised, "PropertyChanged event was not raised correctly.");
}
//Testing a method on the view model has been called
[Test]
public void Should_be_able_to_test_that_insert_method_on_view_Model_has_been_executed()
{
var mock = new Mock<IRepository>();
var employeeVm = new EmployeeVM(mock.Object) {Age = 19};
employeeVm.SaveCommand.Execute(null);
mock.Verify(e=>e.Insert(It.IsAny<Employee>()));
}
WCF Unit Tests
// Test 1 mocking the service
[TestMethod]
public void Should_be_able_to_verify_getCustomer_has_been_called)
{
var mockService = new Mock<ICustomer>();
var expectedCustomer=new Customer{Id=1,Name="Jo"};
mockService.Setup(x => x.GetCustomer(It.IsAny<int>())).Returns(expectedCustomer);
var customerViewModel = new customerViewModel(mockService.Object);
customerViewModel.GetCustomer.Execute(null);
mockService.Verify(x=>x.GetCustomer(),Times.AtLeastOnce());
}
//Test 2 mocking the repository
[TestMethod]
public void Should_be_able_to_verify_getCustomer_has_been_called_on_the_service)
{
var mockRepository = new Mock<IRepositoryCustomer>();
var expectedCustomer=new Customer{Id=1,Name="Jo"};
mockRepository.Setup(x => x.GetCustomer(It.IsAny<int>())).Returns(expectedCustomer);
var customerService = new CustomerService(mock.Object);
customerService.GetCustomer(1);
mockRepository.Verify(x=>x.GetCustomer(),Times.AtLeastOnce());
}
Ok let’s see if I can answer
Integration tests is an overloaded term now.
When you’re writing unit tests, you want to substitute fakes/mocks for timeconsuming/unpredictable/expensive real collaborators so that you can focus on your own code (and assume that the real collabs satisfy an assumed contract). This can help you run your unit tests in a fraction of the time leading to faster feedback and progress. Also a test failure now indicates an error in your code.. the converse being any error in any dependency can cause your test to fail
You also need other (slow) tests that verify if the real collabs (e.g. the DAL) behave as per the contract. (I tend to call these integration tests now)
Private methods should be tested via the public interface which exercises them. Write tests for the public methods which call the private methods.. If this cannot be done, maybe the private methods or parts of it are redundant.
See answer#1- you’re assuming that the real dependencies will behave as per an agreed contract. This allows you to focus on the code you’re writing using the dependencies.
Unit tests should test objects, Acceptance tests verify that all the objects work together when plugged into each other
Write a test that exercises the DAL against a known reference database and verify the expected results. This should be tagged as a slow integration test (as per my chosen definition).