Refactoring & Testability

1. Refactoring & Testability

2. Testing in OOP programming • No life in flexible methodologies and for refactoring-infected developers without SOME kind of AUTOMATED tests • Tests are not a panacea, don't be categorical and skeptic. Tremendous use when possible to write • JUnit is a tool, so "не забивайте гвозди штангенциркулем" • Unit testing forces as to refactor!!!

3. Unit testing benefits (1 of 2) • Can be applied to incomplete application • JUnit is the first User of your code! • Kinds of tests Unit->Integration->Function->Stress • Characteristic is the amount of application build already • Makes me confident that I prevent my peer developers and QAs from finding tedious errors in my code. • Less code to debug under test (as opposed to functional tests)

4. Unit testing benefits (2 of 2) • Can simulate errors • Test not only successful path (as integration test basically does), but the scenario when something can fail! • Testing exceptions • Can act as a perfect and up-to-date documentation • Encourage us for refactoring! Probably the most important advantage.

5. Example. Testing exceptions: try { methodWhichThrowsException(); fail(“Description”); } catch(ApplicationException meaningfulNameExpected) { assertNotNull(“Explanation why expected”,expected) }

6. Mocking • Programming on interfaces vs. concrete classes • Subclassing from concrete classes is a testing smell • If I subclass and override a method, what do I actually test? • MockObjects.com (JMock) • No! business logic. The mock should 100% comply to contract under CURRENT test. JMock is well suited for this rule.

7. Example: • Testing e-mail service.

8. When to use mocks • Notes on page 4

9. Too many mocks? Hard to setup a test? • Mock lower OR refactor! • If a big framework has single but very smart method doWork() it's most likely a bad idea to test it • Test may be skipped if the method's contract is based solely on other contracts

10. Example: • Shopping cart test • (com.luxoft.tests.exercises.shoppingcart)

11. Refactoring • Hardness to write (set up) unit tests FORCES us to simplify (factorize) the method or class or module. • Bad code is impossible to well unit test! • there is one-to-one dependency between good code and ability to write good tests • Code smells (detect manually or by means of PMD, etc.) • Writing tests

12. Refactoring DON’Ts (1 of 3) • Make Your Own Dependencies • Heavy Duty Constructors • Depend on Concrete Classes • Conditional Slalom. if-branches and switch statements • Depend on Large Context Objects • Use Statics • Use Global Flags

13. Refactoring DON’Ts (2 of 3) • Use Singletons Everywhere • Use Primitives Wherever Possible • Look for Everything You Need (Law of Demeter) • Couple functional code directly to the external systems it depends on • Mix Object Lifecycles • Side Effects

14. Refactoring DON’Ts (3 of 3) • Create Utility Classes and Functions/Methods • Create Managers and Controllers • Do Complicated Creation Work in Objects • Utils! • Final Methods • Handcuff your users to Specific Types • Use static initializes

15. Example. Don’t depend on Large Context Objects: class Mechanic { Engine engine; Mechanic(Context context) { this.engine = context.getEngine(); } }

16. Example. Violate the law of Demeter: class Monitor { SparkPlug sparkPlug; Monitor(Context context) { this.sparkPlug = context. getCar().getEngine(). getPiston().getSparkPlug(); } }

17. Inversion of controls & objects construction • Hollywood principle vs. factory method principle • Collaboration graph and construction graph • Remove new operators from application code as much as possible • Conclusion: separate classes with business logic and factories which create classes

18. Example. Avoid new op. for testability: class House { private final Kitchen kitchen = new Kitchen(); private boolean isLocked; private boolean isLocked() { return isLocked; } private boolean lock() { kitchen.lock(); isLocked = true; } }

19. Benefits of IoC • Allows us to mock in tests • Allows us to use single instance of a class (saves us memory) • Shortens the methods and make them more precise (only business logic). • Real isolation.

20. Inversion of controls. Conclusion • It’s good both for tests and for code’s health to: • separate the business logic from factory code to create required objects (for that business logic) • Doing so is really boring! Let the computer do boring stuff. • Use IoC containers • Dependency injection (wiring) • Use empty, param-less constructors. Use setters!

21. Refactoring for testability. Final thoughts • Consider IoC vs. factory method • Example: Isolate system resources getRemoteDataObtainer() • Test coverage and test quality • 100% coverage does not mean that the method is 100% tested. Example. • Test quality measurement tools • Clover • Jester/Muclipse • Oil detector in a car’s engine

22. When Unit tests are good? (1 of 2) • Continuous and automated • Hudson / Email reports • Fast, easy to run • Written early to force Refactoring and detect design errors • No real opportunity to use integration tests • When code is good writing tests is fun. Should be easy

23. When tests are good? (2 of 2) • When there a lots of tests!!! • We MOCK a contract, i.e. believe that a mocked method follows the contract. Test that! • Test as less code outside of the method under test as possible. • Ideally: • test=(test_method_code) + (private_methods) + (mocks)

24. Unit tests is a must activity for a developer • Unit tests are not even a way to test code, but for a developer is a very much a way to develop perfect code • Just try!