How does one go about unit testing static void methods? I have a few more questions:

  1. Is it necessary to unit test database queries like insert, select and update queries ? If so, how does one test them ?
  2. Is unit testing of every method required ? If not, are there any rules I should keep in mind when deciding what methods should be tested?
  3. How would I unit test a method that sends files from one system to another? The input to this method is just the IP address of the target system.
  4. What is the best way of testing private methods that I have written? I have changed the scope to public and tested them. Is this a bad practice?
  5. Must every unit test method have an assert statement? Is it possible to have a unit test without an assert statement? If so, how do I test it?

I am doing the unit testing in C# and I am using MSTest for testing.


1) It is very hard to test static void methods but they must do something so what is it they do? If they modify global state you could read that global state, but the best thing is to refactor them into a better structure.

2) Unit testing is only for public methods. Even if you test all methods you can probably not input all parameter combinations so even if there are tests there can still be bugs. If you only write production code provoked by a failing test(TDD) it will be much clearer which tests are needed.

3) This is not a unit test but an integration test. Is it possible to read the file back somehow? What is how I would write that integration test.

4) Don't test private methods. They are not part of the contract and you are free to change them as long as it doesn't change the behaviour of public methods. If you feel there is too much going on in the private methods, feel free to move some of the logic into a service and inject that instead.

5) In some cases it makes sense to have a unit test that checkes that some code runs without throwing an exception and in that case assert is not needed.

  • 1
    Unit testing isn't strictly for only public methods. Many people adhere to that strategy but it's not strictly true. Unit testing is for any unit that you care is functionally correct. May 6 '15 at 14:28
  • 1
    @BryanOakley: Even if you subscribe to that ideology, you should not make them public just to test them. A good case for testing only public methods is that you can find out if you have dead code in private methods.
    – Magus
    May 6 '15 at 16:05
  • Nice answers. But you left out Nr. 1. Your 1st answer is his "Nr.0". Question Nr.1 is about sql-queries. Perhaps you could add another point "inject an db-connection to test a query" or something..
    – kara
    Dec 27 '18 at 13:00

Without gettting into an argument over what a 'unit' test is:

  1. Yes you should test your sql/sprocs. especially if you (foolishly) put business logic in them. you can use database snapshots to set up dbs


  1. 'Test all your methods' is a good rule because it allows no room for interpretation. When you are a rock star programmer (like me) you can test a subset of your methods (YOLO!)

  2. Abstract the underling stream writing so that you are able to inject a mock stream and test the logic without actually sending data between systems. ie ip address not found, connection lost etc

  3. Reflection, internalsVisibleTo or (my fave) Make it protected, inherit the class and add a public accessor


  1. Yes, you can even assert that an exception is thrown


Not the answer you're looking for? Browse other questions tagged or ask your own question.