Reversed Tests Pyramid Dealing With Legacy Code
Wiktor onowski
@streserhttp://www.agileszkolenia.pl
http://codesprinters.com
@pragmaticcodershttp://pragmaticcoders.com
Can you imagine perfect software?
Tests pyramid
Unit Tests
Functional/Integration Tests
End to End Tests
It would be perfect to work with perfect software every
day...
But!
Reality...
Is...
Different!
Legacy Code
How did we get to this point?
It's all because of the money...
Technical Debt
Sometimes Technical Debt could be considered as something
good...
Unfortunately temptation of easy making money is huge...
People lives in illusion of continuous, fast and low cost
development...
Forgetting about the Quality...
Success in Software Development is something which is not
continuous...
Success is state that you can achieve but also lose very fast if
you can't respond to changes fast enough...
So, is it possible to deal with legacy code?
Reversed Tests Pyramid
End-to-End Tests
Functional/Integration Tests
Unit Tests
- What?!
You can't do unit testing when there are no units in your
software...
You can't do integration tests when there is nothing to
integrate...
You need to refactor your code so it would be testable...
How to refactor without tests?!
Now refactor...
High level tests gives you courage to refactor your code...
But.. There are few reasons why you shouldn't reverse tests
pyramid
End-To-End tests are too long...
End-to-end tests are difficult to maintain...If we need
end-to-end tests we are probably doing something wrong with our
architecture...
So it's all about reversing back our tests pyramid.
Step by step we are introducing new architecture...
Remember that creating reversed tests pyramid and reversing it
back will take some time...
But you need to do this if you want to pay your technical debt
back!
Few final thoughts...
Keep your technical debt as low as possible and try to pay it
back every time you can. For example use your slack time for
that!
Remember - WHY we are doing this?
Leave the world better then you found it
Few final thoughts...
Beware of refactoring just for refactoring!
Few final thoughts...
Beware of refactoring just for refactoring!
Resist temptation to re-write from scratch history is against
you, such projects usually fail.
Remember to always remove your (duplicated) tests!
Software quality in many cases could be understood as ability to
introduce changes into software!
Keep your technical debt as low as possible and try to pay it
back every time you can. For example use your slack time for
that!
Resist temptation to re-write from scratch history is against
you, such projects usually fail.
Few final thoughts...
Beware of refactoring just for refactoring!
Resist temptation to re-write from scratch history is against
you, such projects usually fail.
Remember to always remove your (duplicated) tests!
Software quality in many cases could be understood as ability to
introduce changes into software!
Keep your technical debt as low as possible and try to pay it
back every time you can. For example use your slack time for
that!
Remember to always remove your (duplicated) tests!
False positive or false negative safety net is even worst than
lack of safety net...
Software quality in many cases could be understood as ability to
introduce changes into software!
Wiktor onowski
agileszkolenia.pl
Questions?
@streserhttp://pragmaticcoders.comhttp://codesprinters.com
Click to edit the title text formatClick to edit Master title
style
14-9-15
