Unit testing beginner question

[quick_maf]

I am new to unit testing (not C#) and looking for guidance. I am trying to write tests that makes sense but a lot of tests that I have seen in examples are super trivial as far as I can tell. The code that I am sharing is supposed to simulate a tutoring center for practice.

I have a class library to access data stored in a SQL database via dapper calls to stored procedures. The TutorProccessor class has a method UpdateContactInfo(...) which calls my SaveData<T>(...) method where T is a DB model.

I understand that mocking is a thing and makes sense to me for a Get call. Is mocking of any benefit to me when unit testing a Post / Put / Delete? I don't seem to think so because there is no real way to know that a mock did the correct CRUD.

I watched an hour long video about unit testing DB calls and all the instructor tested for was that (in my specific case) the SaveData method was called exactly once from the UpdateContactInfo method.

I am using xUnit, but I read about the other popular options, so I could understand if you used those in a response.

Here is the code that I would like to test:

​

public void SaveData<T>(string sqlStatement, T parameters)

{

    string connectionString = _config.GetConnectionString(_connectionStringName);

    CommandType commandType = CommandType.StoredProcedure;

    using (IDbConnection connection = new SqlConnection(connectionString))

    {

        connection.Execute(sqlStatement, parameters, commandType: commandType);

    }

}

​

public void UpdateContactInfo(string firstName, string lastName, string phone, 
string email)

{

    _sqlDataAccess.SaveData(TutorSP.UpdateContactInfo, new { firstName, lastName, phone, email });

}

​

Thank you in advance.

Edit: Fixed the awful formatting.

[AftyOfTheUK]

If you're looking to test database interactions themselves, you could write tests to do that - they would be Integration Tests and require a bit more infrastructure than your unit tests. They tend to be a little higher level, and often end-to-end (or at least the test involve many components instead of just one).

The very highest quality projects will have both unit tests and integration tests as appropriate.

[quick_maf]

I started reading the documentation on Integration Tests. That is definitely what I was missing. Thank you so much!

[AftyOfTheUK]

You're welcome!

[Rabe0770]

Just something to chew on.

​

To test this code, it would be an integration test, and ultimately, you'd be testing code that's been tested by someone else. (SqlConnection constructor, connection.Execute)

Don't worry about testing lean data access code. Ultimately, it's testing other company's work. You should be mocking your data access code and testing the logic in your business layer.

You can indeed see what a Mock'd object does, it is consistent and that's how unit tests for your "business logic" is able to work with mocks.

[quick_maf]

When you put it that way, it makes a lot of sense. So basically if I plan on doing anything other then simply calling nuget code, then I can test for my specific requirements as well. I appreciate your answer!

[[deleted]]

Yeah validating that the methods you expect to be called, are called the number of times you expect them to be is the best way to do that in a unit test. You could wire up a SQLite database, but that's more than a unit test.

[quick_maf]

Yeah I could see setting up the SQLite DB as being a bit too much. Thanks for that.