I am involved with a project which must, among other things, controlling various laboratory instruments (robots, readers, etc...)
Most of these instruments are controlled either through DCOM-based drivers, the serial port, or by launching proprietary programs with various arguments. Some of these programs or drivers include simulation mode, some don't. Obviously, my development computer cannot be connected to all of the instruments, and while I can fire up virtual machines for the instruments whose drivers include a simulation mode, some stuff cannot be tested without the actual instrument.
Now, my own code is mostly not about the actual operations on the instruments, but about starting operations, making sure everything is fine, and synchronising between the lot of them. It is written in Java, using various libraries to interface with the instruments and their drivers.
I want to write unit tests for the various instrument control modules. However, because the instruments can fail in many ways (some of which are documented, some of which aren't), because the code depends on these partially random outputs, I am a bit lost regarding how to write unit tests for these parts of my code. I have considered the following solutions:
- only test with actual instruments connected, possibly the most accurate method, but it is not practical at all (insert plate in reader, run unit test, remove plate, run unit test, etc...), not to mention potentially dangerous,
- use a mock object to simulate the part that actually communicates with the thing; while this one is definitely easier to implement (and run), it may not be able to reproduce the full range of potential failures (as mentioned above, a lot is undocumented, which can sometimes cause bad surprises)
While I am currently thinking of going with the latter, am I missing something? Is there a better way to do this?
以上就是Unit-testing code with unpredictable external dependencies的详细内容，更多请关注web前端其它相关文章！