This is a ‘dangerous test’. This is why you have to be careful with mocks as you could end up testing nothing at all. The test is dangerous because even though all the desired outcomes are checked correctly, one of those outcomes will always pass. The culprit is the setup of one of the mocks. Its setup already contains the desired result that will be verified later on. It is only one aspect of the desired outcomes that will always pass, so it might easily be overlooked. This could have been an annoying bug. Anyway, this test was generated before the actual code it should test. I noticed that it failed ‘too late’, for the wrong reason. I expected it to fail because the code that should set the status of the sensor hasn’t been written, Actually, now that I come to think of it… maybe I shouldn’t be testing the status of the sensor at all in this test. The TaskClient component is responsible for updating the status. Why? Scheduling a task is a web request which can fail for numerous reasons. So it succeeds, then the status should be set to ‘updating_firmware’. If it fails, it should be set to ‘update_failed’. On the other hand: if the TaskClient returns a sensor with a status ‘updating_firmware’, it shouldn’t change anymore during the validation process… Hmmm… anyway, the point of the post is that you need to be alert when working with mocks.
Testing something that came from a mock is a sure indicator that either you are over-mocking, or you are over-asserting. Though, it does look like your test is checking that the sensorValidationProcess calls scheduleFirmwareUpdate with this assertion. I expect that is an async method though and I'd be very suspicious that this test isn't properly testing that aspect.
Web & Backend · Cloud & Edge Computing | Senior R&D Software Engineer | PhD in Computer Engineering
2dMmm… what if you were veryfying that sensorValidationProcess.process doesn’t change the status of the sensor?