测试还是不测试-键盘挂钩功能

Question

I've never used TDD and unit testing "properly", but would like to learn some techniques. Could you please help me with the idea on writing test methods for this not-so-testable (in my opinion) case.

The class I want to test is yet to be written (I remember, I need to write the test first), but it will have a method to hook on Windows shortcut key combination (passed as parameter) and will raise an event when that key combination is pressed. So how do I go about testing such a case? Do I need to write key press simulation routine first? Do I need a unit test for key press simulation or will the shortcut hook test "cancel out" the need for it? Is this a unit test or is it called some other way altogether?

The point of this question is rather educational, I perfectly understand that this is not the best case for unit testing and is probably not worth the effort. I just want to use non-trivial scenario for better understanding of the principles.

Answer 1

I would assume you would first start out by writing a test that directly called the Hook method and check that a) some event got raised or b) some value got set in the class under test.

The hard stuff like a keyboard event simulator would come later (if it's even needed). This would be the first step and would influence the way you design your hook class. It would hopefully influence it in such a way that makes your hook class extensible enough to work with Windows short cuts and with your unit tests.

Answer 2

I tend to agree with cmw.

The general approach is to unit test the logic of the code you have written, not the plumbing you depend on from Windows (or any other outside "service")

Testing the actual keyboard press functionality, IMO, would be an "integration" test. Something done as part of a test script, for instance, that would be performed by QA.

The key to unit testing this scenario is decoupling the dependency on the key press action from the logic in them method that responds to the key press. This is where unit tests become very valuable. They highlight areas of your code that can be re-factored to adhere to the SRP .