Upload
neal-maurice-sullivan
View
215
Download
0
Embed Size (px)
Citation preview
Refactoring & Testability
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!!!
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)
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.
Example. Testing exceptions:
try {
methodWhichThrowsException();
fail(“Description”);
} catch(ApplicationException meaningfulNameExpected) {
assertNotNull(“Explanation why expected”,expected)
}
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.
Example:
Testing e-mail service.
When to use mocks
Notes on page 4
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
Example:
Shopping cart test (com.luxoft.tests.exercises.shoppingcart)
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
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
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
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
Example. Don’t depend on Large Context Objects:
class Mechanic {
Engine engine;
Mechanic(Context context) {
this.engine = context.getEngine();
}
}
Example. Violate the law of Demeter:
class Monitor {
SparkPlug sparkPlug;
Monitor(Context context) {
this.sparkPlug = context.
getCar().getEngine().
getPiston().getSparkPlug();
}
}
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
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;
}
}
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.
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!
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
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
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)
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!