Testing the untestable

Testing the Untestable Taming production code Roy Klein Flash Client Team Leader Wix.com

Overview Test Driven Development Overview The motivations for and challenges of testing our production code Techniques + a real life example

Unit Testing Exercise classes in an isolated environment Verify that actions on the code produce predictable, consistent results Write Tests Write Code Pass All Tests Refactor

The price of Unit Testing New logic is more time consuming to write Old logic may require extensive Refactoring to be testable Amount of code to maintain increases Illusion of being bug free when tests pass No Stage in FlexUnit The actual visual output can’t be fully tested

The benefits of Unit Testing Better definition and understanding of the code’s purpose Helps improve code design Empowers refactoring Documents the usage of the code A small, quick environment to debug in Provides immediate feedback when the code changes (Adding/modifying functionality, Refactoring, Merging)

TDD ROI conclusions The price: Initial additional development time The benefit: Cumulative reduction in defects The conclusion: No brainer for long term projects

The Challenges Classes and functions have multiple responsibilities Classes are strongly coupled to other classes Some of these couplings are to Singletons Ambiguous dependencies (Objects, callbacks) In short, code changes have unknown side effects that are hard to foresee

The Motivation Our production code is the result of several years of rat chase Rapid Development Refactoring core code is dangerous Augmenting core capabilities is expensive Reducing code volatility may save us from a dangerous rewrite, or allow us to reuse code when a rewrite occurs Moving to CI is key to remaining competitive

Legacy Testing Heuristic Before making the change, write passing tests for the area around your change These tests are intended to preserve the behavior of the code prior to your change Add failing tests that define the change you’re making Apply your change and make all tests pass

Replace Dialog: Dependency Breaking

Safe Modification: Function extraction Preserve the original functions’ signature.

1. Preserve function signature

Safe Modification: Function extraction Preserve the original functions’ signature. Extract the function to its own class

2. Extract the modified function

Safe Modification: Function extraction Preserve the original functions’ signature. Extract the function to its own class Call the new function with the same signature, and a reference to an interface representing the original class

Safe Modification: Function extraction Preserve the original functions’ signature. Extract the function to its own class Call the new function with the same signature, and a reference to an interface representing the original class Use the IDE to determine what calls are to be redirected to the original class

4. Use IDE to find what’s missing

Safe Modification: Function extraction Preserve the original functions’ signature. Extract the function to its own class Call the new function with the same signature, and a reference to an interface representing the original class Use the IDE to determine what calls are to be redirected to the original class Put those calls in the interface

5. Put what’s missing in the interface

Safe Modification: Function extraction Preserve the original functions’ signature. Extract the function to its own class Call the new function with the same signature, and a reference to an interface representing the original class Use the IDE to determine what calls are to be redirected to the original class Put those calls in the interface Create a mock class implementing the interface for testing

Breaking encapsulation on purpose Encapsulation is a tool that makes the code usage easier to understand The need to break it often points to problem in the design of the code usage Problems in design can’t be solved without Unit Tests in place The break can help in understanding what needs to be changed Damage can be minimized with self documenting code

Breaking encapsulation on purpose

Solving Singletons dependency You can’t use a testing instance Create a testing only function to set a testing instance

Solving Static dependencies You can’t subclass or mock a static class Replace reference to static variables with getters and static functions to local functions Subclass and override with a test class to use your own data/logic In case of a massive amount of static calls, use the same class name in your testing project to override the original class, and delegate all calls to another class

Conclusion Getting legacy code into a testing environment is possible Most of the benefits of TDD can be achieved with partial coverage Adapting TDD during any stage of the development is worthwhile. The bigger the project, the more beneficial it is

Testing the untestable

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (19)

Similaire à Testing the untestable

Similaire à Testing the untestable (20)

Dernier

Dernier (20)

Testing the untestable

Notes de l'éditeur