In addition to @Arseni's answer.
Your method depends on the database. Even
db variable is an interface you still passing query which depends on the database type or database version etc.
Unit tests are tests which are separated from any IO operations (File system, Web service or database). Because unit tests are tests which developer need to run every 1 minute and execution time of tests need to be very short (seconds). While tests with involved IO operation takes longer time.
Tests which depend on IO operations have place to be, but they called "Integration tests".
So if your method is part of Data layer then you can write integration test where you can run another
SELECT query and assert that
ClockIn column isn't
NULL after updating.
But if your method is part of Business logic then for proper unit testing you need abstract this method to the interface for example. Then while testing a method which will use
UpdateEmployeeClockIn you can assert that
UpdateEmployeeClockIn method was called with correct parameter.
Your method have another case which can make your testing almost impossible. You using system's datetime function
ClockIn = GETUTCDATE(). Function
GETUTCDATE() always return different value. You cannot create expected value against which your result can be asserted.
Because you using time from database then I suggest move time method to the dedicated function in your interface. Which can be mocked up and return defined expected value for the testing
public interface IDataService
void UpdateEmployeeClockIn(int employeeId, DateTime timeIn);
Then in your Business logic layer
public class EmployerManager
private readonly IDataService _dataService;
public Employer(IDataService dataService)
_dataService = dataService;
public void UpdateClockinWithCurrentTime(int employerId)
DateTime currentTime = _dataService.GetCurrentTime();
In this case you can write unit tests for the method
UpdateClockinWithCurrentTime where you can tests through mock of
UpdateEmployeeClockIn was executed with correct parameters.