title: Should you unit test constructors of abstract classes and, if so, how?
body: <p>Supposing you have an abstract base class like this:</p>
  <pre><code>public abstract class WebApiServiceBase
      {
          public WebApiServiceBase(
              HttpClient httpClient)
          {
              HttpClient = httpClient ?? throw new ArgumentNullException(nameof(httpClient));
          }
  
          protected HttpClient HttpClient { get; }
  
  // For brevity, omitted some instance methods that can be used by derived classes
  }
  </code></pre>
  <p>The class knows it needs the HttpClient in the constructor so it throws an error if it's null. Should this error-throwing functionality be unit tested?</p>
  <p>If so, what's the best way, seeing as you can't directly instantiate an abstract class in your unit tests like this:</p>
  <pre><code>    [TestClass()]
      public class WebApiServiceBaseTests
      {
          [TestMethod()]
          public void WebApiServiceBase_NullHttpClient_ThrowsArgumentNull()
          {
              //Arrange
              Action action = () =&gt; {
                  var controller = new WebApiServiceBase(null); // Won't compile, of course, because you can't directly instantiate an abstract class
              };
  
              //Act
              //Assert
              Assert.ThrowsException&lt;ArgumentNullException&gt;(action);
          }
      }
  </code></pre>
  <p>I understand there are many things I <em>could</em> do:</p>
  <ul>
  <li>Only test the error-throwing functionality in derived classes.</li>
  <li>Invent a new derived class in the test code just for testing this.</li>
  <li>Don't make classes like this abstract in the first place.</li>
  <li>Probably some other ideas I haven't thought of too.</li>
  </ul>
  <p>But what <em>should</em> I do? What's the <em>best practice</em>?</p>