Reversed Tests Pyramid

Wiktor onowski

@streserhttp://www.agileszkolenia.plhttp://www.codespritners.com

Agile Coach

Who am I?

Troublemaker

Passionate

Can you imagine perfect software?

Functional/Integration Tests

Unit 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 the temptation of
easy money is huge...

People live in an illusion of continuous, fast, low cost software development...

Forgetting about the Quality...

Success in Software Development is something that is
not continuous...

Success is a state that you can achieve but also loose very quickly 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...

Now refactor...

High level tests give you courage to refactor your code...

But.. There are a few reasons why you shouldn't reverse tests pyramid

End-To-End tests are too long...

End-to-end tests are difficult (costly) 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
a new architecture...

Remember that creating reversed tests pyramid and reversing it back will take some time...

Remember - WHY are we doing this?

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!

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 a safety net...

Software quality in many cases could be understood as ability to introduce changes into software!

Wiktor onowski
www.codesprinters.com

Questions?

@streserhttp://medium.com/@streserhttp://blog.testowka.plhttp://www.agileszkolenia.plhttp://codesprinters.com

Click to edit the title text formatClick to edit Master title style

13-11-6