How to find places in code that must be covered with unit tests

Question

I know it's not so good to write tests after you actually wrote code. I'm unit-testing newbie and feel that unit-testing may deliver many good advantages so I obsessed with an idea to cover as much as possible.

For instance, let we have this code:

public class ProjectsPresenter : IProjectsViewObserver
{
    private readonly IProjectsView _view;
    private readonly IProjectsRepository _repository;

    public ProjectsPresenter(IProjectsRepository repository, IProjectsView view)
    {
        _view = view;
        _repository = repository;
        Start();
    }

    public void Start()
    {
        _view.projects = _repository.FetchAll();
        _view.AttachPresenter(this);
    }

}

So looking on code above could you answer me what tests typically I should write on that piece of the code above?

I'm rolling on write tests on constructor to make sure that repository's FetchAll was called and on the view site AttachPresenter is called.

POST EDIT

Here is a my view interface:

public interface IProjectsView
{
    List<Project> projects { set; }
    Project project { set; }

    void AttachPresenter(IProjectsViewObserver projectsPresenter);
}

Here is a view:

public partial class ProjectsForm : DockContent, IProjectsView
{
    private IProjectsViewObserver _presenter;
    public ProjectsForm()
    {
        InitializeComponent();
    }

    public Project project
    {
        set
        {
            listBoxProjects.SelectedItem = value;
        }
    }

    public List<Project> projects
    {
        set
        {
            listBoxProjects.Items.Clear();   
            if ((value != null) && (value.Count() > 0))
                listBoxProjects.Items.AddRange(value.ToArray());
        }
    }

    public void AttachPresenter(IProjectsViewObserver projectsPresenter)
    {
        if (projectsPresenter == null)
            throw new ArgumentNullException("projectsPresenter");

        _presenter = projectsPresenter;
    }

    private void listBoxProjects_SelectedValueChanged(object sender, EventArgs e)
    {
        if (_presenter != null)
            _presenter.SelectedProjectChanged((Project)listBoxProjects.SelectedItem);
    }
}

POST EDIT #2

This is how I test interaction with repository. Is everything allright?

    [Test]
    public void ProjectsPresenter_RegularProjectsProcessing_ViewProjectsAreSetCorrectly()
    {
        // Arrange
        MockRepository mocks = new MockRepository();
        var view = mocks.StrictMock<IProjectsView>();
        var repository = mocks.StrictMock<IProjectsRepository>();
        List<Project> projList = new List<Project> {
            new Project { ID = 1, Name = "test1", CreateTimestamp = DateTime.Now },
            new Project { ID = 2, Name = "test2", CreateTimestamp = DateTime.Now }
        };
        Expect.Call(repository.FetchAll()).Return(projList);
        Expect.Call(view.projects = projList);
        Expect.Call(delegate { view.AttachPresenter(null); }).IgnoreArguments();
        mocks.ReplayAll();
        // Act
        ProjectsPresenter presenter = new ProjectsPresenter(repository, view);
        // Assert
        mocks.VerifyAll();            
    }

The rhino mocks example seems unrelated... Maybe it deserve seperate question. Anyway, you'd probably want to look at rhino mocks AAA syntax, e.g. http://stackoverflow.com/questions/2124175/rhino-mocks-aaa-quick-start — Amittai Shapira, May 01 '12 at 14:00

k.m · Accepted Answer · 2012-05-01T13:50:19.950

I know it's not so good to write tests after you actually wrote code

It's better than not writing tests at all.

Your method works with two external components and that interaction should be verified (in addition to mentioned arguments validation). Checking whether FetchAll was called gives you no value (or checking it returns something - this belongs to ProjectsRepository tests itself) - you want to check that view's projects are set (which will indirectly check whether FetchAll was called). Tests you need are:

verify that view projects are set to expected value
verify that presenter is attached
validate input arguments

Edit: example of how you would test first case (projects are set)

// "RegularProcessing" in test name feels a bit forced;
// in such cases, you can simply skip 'conditions' part of test name
public void ProjectsPresenter_SetsViewProjectsCorrectly()
{
    var view = MockRepository.GenerateMock<IProjectView>();
    var repository = MockRepository.GenerateMock<IProjectsRepository>();
    // Don't even need content;
    // reference comparison will be enough
    List<Project> projects = new List<Project>();
    // We use repository in stub mode;
    // it will simply provide data and that's all
    repository.Stub(r => r.FetchAll()).Return(projects);
    view.Expect(v => v.projects = projects);

    ProjectsPresenter presenter = new ProjectsPresenter(repository, view);

    view.VerifyAllExpecations();
}

In second case, you'll set expectations on view that its AttachPresenter is called with valid object:

public void ProjectsPresenter_AttachesPresenterToView()
{
    // Arrange
    var view = MockRepository.GenerateMock<IProjectView>();
    view.Expect(v => v.AttachPresenter(Arg<IProjectsViewObserver>.Is.Anything));
    var repository = MockRepository.GenerateMock<IProjectsRepository>();

    // Act
    var presenter = new ProjectsPresenter(repository, view);

    // Assert
    view.VerifyAllExpectations();
}

Should I implement first and second item in two different tests or just in one test? — kseen, May 01 '12 at 10:23
@kseen: those should be two tests as they're **not related** except for interacting with same component. — k.m, May 01 '12 at 11:42
Please take a look at my question update. I attached view's details. Please tell me how can I test that presenter was attached rightly? — kseen, May 01 '12 at 11:47
And please make me clean about interacting with repository looking at post edit #2. Thanks in advance! — kseen, May 01 '12 at 11:50
Take a look at `IProjectsView` interface. There is only property setter on `IProjectsView.projects`. So assertion part won't work: `Project.Forms.Projects.IProjectsView.projects cannot be used in this context because it lacks the get accessor` — kseen, May 01 '12 at 13:48
Thanks! I have another one question on second case: how can we make sure that `AttachPresenter` is called with specific presenter? In your code we have `Arg.Is.Anything` which means that any argument will produce right result. — kseen, May 01 '12 at 14:03
@kseen: don't think that's possible; at the time of setting expectations, you'll need to have `ProjectsPresenter` object constructed. Since your action takes place in ctor, this is not possible then. You can expose `_presenter` as internal field and check that field after at the end. — k.m, May 01 '12 at 15:38

score 0 · Answer 2 · answered May 01 '12 at 06:14

0

I would add simple tests at start , like:

null reference checks
FetchAll() returns any value

Do not add a lot of test code at first time, but refine them after as your dev code mutates.

answered May 01 '12 at 06:14

Tigran

61,654
8
86
123

null reference check seems like a good idea! Thanks! I'm not so clear about your point on 'FetchAll() returns any value'. Could you please describe it more widely? – kseen May 01 '12 at 06:21
@kseen: I mean, check if `FetchAll()` returns any value in the `_view.projects = _repository.FetchAll();`. In other words if the program is able to find *any* project available (don't know if this is a crucial point for your app, but just *intent* that yes) – Tigran May 01 '12 at 06:27

score 0 · Answer 3 · answered May 01 '12 at 06:19

0

I would add tests for exception e.g. ArgumentException, corner cases and usual ones of FetchAll().

PS. Does start have to be public?

answered May 01 '12 at 06:19

Lukasz Madon

14,664
14
64
108

Better question is that does start() have by called in constructor. – Damian Leszczyński - Vash May 01 '12 at 06:21

score 0 · Answer 4 · answered May 01 '12 at 07:44

Pex is an interesting tool that's worth checking out. It can generate suites of unit tests with high code coverage: http://research.microsoft.com/en-us/projects/pex/. It doesn't replace your own knowledge of your code - and which test scenarios are more important to you than others - but it's a nice addition to that.

score 0 · Answer 5 · answered Mar 20 '17 at 20:55

The purpose of writing tests before writing production code is first and foremost to put you (the developer) in the mind-set of "how will i know when my code works?" When your development is focused on what the result of what working code will look like and not the code itself you are focused on the actual business value obtained by your code and not extraneous concerns (millions of man hours have been spent building and maintaining features users never asked for, wanted, or needed). When you do this you are doing "test driven development".

If you are doing pure TDD the answer is 100% code coverage. That is you do not write a single line of production code that is not already covered by a line of unit test code.

In Visual Studio if you go to Test->Analyze Code Coverage it will show you all of the lines of code that you do not have covered.

Practically speaking its not always feasible to enforce 100% code coverage. Also there are some lines of code that are much more important then others. Determining which depends once again on the business value provided by each line and the consequence of that line failing. Some lines (like logging) may have a smaller consequence then others.

How to find places in code that must be covered with unit tests

5 Answers5