-1

I would like to write a unit test to check HashSet in C# MSTest to cover ICollection of my class, like this:

public ICollection<ObjectClass> Object { get; private set; } = new HashSet<ObjectClass>();

enter image description here

Does anybody know how to Assert this section of the code?

Edit1: I didn't want to ignore or exclude auto-property initializers I am looking a way to test them

Payam Khaninejad
  • 7,692
  • 6
  • 45
  • 55
  • 1
    I would not test that it is a HashSet tough, as the class exposes an ICollection. I would only test that it is not null and empty when I create a new instance of the class (assuming that is a property of a non static, non abstract class and all that). – Monticola Explorator Jan 23 '19 at 08:32
  • 7
    I think this shouldn't be tested at all – Marco Salerno Jan 23 '19 at 08:32
  • 2
    @Marco Indeed, it already has [tests](https://github.com/dotnet/corefx/blob/a10890f4ffe0fadf090c922578ba0e606ebdd16c/src/System.Collections/tests/Generic/HashSet/HashSet.Generic.Tests.cs). – ProgrammingLlama Jan 23 '19 at 08:35
  • it's true but the coverage test shows this needs to be tested either. – Payam Khaninejad Jan 23 '19 at 08:37
  • You will test this when you write tests for the class where this collection is used. You don't need to write tests for this property separately. – Fabio Jan 23 '19 at 08:50
  • What tool are you using to measure the test coverage? – Tim Schmelter Jan 23 '19 at 08:50
  • @Rango ReSharper – Payam Khaninejad Jan 23 '19 at 08:51
  • 1
    [When asking a question about a problem with code, people who are volunteering to help need the text of the code. Images of the code are not an acceptable substitute.](http://idownvotedbecau.se/imageofcode) – Liam Jan 23 '19 at 08:54
  • 2
    Arbitrary 100% coverage reports are nonsense. What does testing this achieve? – Liam Jan 23 '19 at 08:55
  • @Liam I don't know, I asked the community how to test. – Payam Khaninejad Jan 23 '19 at 08:55
  • 1
    @MarcoSalerno is right, the answer is don't. – Liam Jan 23 '19 at 08:56
  • @Liam then If I removed the HashSet in my code will be ok? I don't think so – Payam Khaninejad Jan 23 '19 at 08:57
  • 1
    Have you read [this](https://stackoverflow.com/questions/32329430/exclude-auto-properties-from-code-coverage-in-visual-studio-2015) and [this](https://dotnettools-support.jetbrains.com/hc/en-us/community/posts/206618825-DotCover-ignore-simple-Getters-and-Setters-in-Analysis)? – Tim Schmelter Jan 23 '19 at 09:05
  • @Rango it's a solution when you want to exclude but I want to know if there is a way to tests or not. – Payam Khaninejad Jan 23 '19 at 09:07
  • 2
    @PayamKhaninejad: it's a bug which came with auto implemented properties, you should not test. The latest version of dotCover should have fixed it. MSTest's Code Coverage analysis has the same bug – Tim Schmelter Jan 23 '19 at 09:08

1 Answers1

3

You don't need a test that checks that the underlying implementation of ShiftTemplateCalendar is of a specific type.

You have to write tests that use this property (e.g. add / remove an element) or at least check that this property is never null (even right after constructing the object that holds the collection).

In one of your comments you asked, if it would be okay to remove this property from your class. As we can see in your screenshot, there are 3 of 3 tests passing this property. So if there are at least 3 tests using this property, why shouldn't that line be tested?

Seems to be a bug in your coverage tool.

Oliver
  • 43,366
  • 8
  • 94
  • 151