The document discusses reversing the traditional tests pyramid when dealing with legacy code. It notes that with legacy code, there may be no true units to unit test. Instead, it advocates starting with end-to-end tests to build confidence to refactor the code into units and add integration and unit tests. However, it warns that end-to-end tests are long to maintain. The goal is to slowly reverse the tests pyramid by refactoring code into units and adding tests at each level to manage technical debt over time. Paying down technical debt is important to maintain the ability to change software.
28. Now refactor...
High level tests gives you courage to refactor your code...
●
29. Now you can refactor and introduce
some units into your software...
30. But.. There are few reasons why you shouldn't
reverse tests pyramid
End-To-End tests are too long...
31. End-to-end tests are difficult to maintain...
If we need end-to-end tests we are probably doing something
wrong with our architecture...
32. So it's all about reversing back our
tests pyramid.
33. Step by step we are introducing new
architecture...
34. Remember that creating reversed tests
pyramid and reversing it back will take
some time...
35. But you need to do this if you want to
pay your technical debt back!
36. 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!
40. 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.
41. 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!
●
Remember to in many cases could your (duplicated) tests!
Software quality always remove 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!
42. False positive or false negative safety
net is even worst than lack of safety
net...
43. ● Software quality in many cases could be understood as
ability to introduce changes into software!