Extract Class<\/strong><\/p>\n Starting from the methods that I extracted in the testing class I make them static and then extract them to a new class. The methods from the extracted class are then static. I change the static call with a call to an instance created in the setup of the test. There is a small trick I use when doing that, so that I am always on green while refactoring. Check the codecast to spot it!<\/p>\n The Rule of Three – extract class<\/strong><\/p>\n In this case as well The Rule of Three applies: only extract duplication when spotted at least three times. When extracting methods to a new class I need at least three methods that belong together.<\/p>\n As mentioned in the previous articles, this is just a guideline. If you are sure, extremely sure, that one method should be extracted, then go for it. But be careful not to generalize to soon. Premature generalization is the root of all evil<\/em> (Donald Knuth paraphrase).<\/p>\n Testability – Guidelines<\/strong><\/p>\n Because all the tests are calling the extracted class, it is tested as well, but indirectly. This is a classicist TDD approach where I don’t mind if I test a few classes together, without any dependency injection, stubbing or mocking. Another approach would be to start adding tests to the extracted class, after it was extracted. It is a question of style, but there are also some guidelines to this. <\/p>\n Check the video below with the codecast:<\/p>\n
\nThe extracted class needs to either have only logic, or only to hold data.<\/em>
\nWhenever I don’t have any logic in the extracted class, I won’t add new tests.<\/em>
\nIf the extracted class has logic, but it is trivial, I will use the existing indirect tests.
\nIf the extracted class has a lot of logic, I will split the existing tests to have specific tests for the extracted class, and smaller (simpler) initial tests.<\/em><\/p>\nVideo<\/h2>\n