Wiktor Żołnowski


Wiktor Żołnowski from Code Sprinters.

I’m Agile Coach, Consultant and Trainer focused on process improvements and basic technical practices like TDD, BDD, Emergent Architecture and Pair Programming. During last few years I was participating and leading couple Agile transformations in various IT organisations.

I have about 6 years of experience in IT business – from Software Tester, through Programmer, QA Engineer to Scrum Master, Manager and QA Lead. Working on various projects in different methodologies like Waterfall, RUP and finally Scrum and Kanban with some XP practices I’ve learned that everything starts from the people in organisation and it’s all about their knowledge so I became Trainer. Now I’m learing Scrum and XP practices and coaching few teams in continous improvements of their technical practices.

Since I discovered something called “Agile” few years ago I’m trying convince other IT people that appropriate methodology and good practices in software development are only what they need to assure best quality for the products.

I am passionate in pragmatic approach to everything what I’m doing and I hate wastes.


Reversed Tests Pyramid – dealing with legacy code

Language: EN

Almost every experienced test engineer and programmer heard about tests pyramid which tells us that our automated tests should be about 80-90% – unit tests, 5-15% – some functional, integration or acceptance tests and 1-5% – end to end, GUI tests. It sounds great and of course is possible. That structure of tests has some implications like modularand separated architecture, good abstractions model, data model separation from functionality and logic, etc. Everything works and is quite easy to implement when we starting new, “greenfield” project, or dealing with code written in a good, simple way with “is it testable?” question always behind every line of code.

Some Clean Code and TDD practitioners says that you shouldn’t write end-to-end or even functional tests at all and database or user interface are (un)necessary evil. Can you imagine application like this? I can! Writing applications that way would be great, and likelihood ofbugs is pretty low. Maintainability would be wonderful – new changes in modular, almost independent architecture are extremely easy to implement. We can enumerate the advantages of such approach without endlessly… But…

Unfortunately, the reality is completely different. Most of us – developers, are dealing with already written code (written few years or even decades ago), which is not understandable by no-one, and no-one knows which particular lines or functions are really doing. Code which is unpredictable – every change could introduce bugs in other parts of the system which we would never expect that is somehow connected with the changed one. This code is sometimes measured in KLOC’s – Kilo Lines Of Code and this numbers maybe really high.Code like this was implemented sometimes by few hundreds or even thousands programmers, or even by few generations of programmers. Sometimes people who could know something about it are far away in another job, or they even died.

But don’t worry – there are some practices which would help you (us) with “Legacy Code” (because this is the proper name for code described above). One of this practice which I would like to share with you is reversed tests pyramid.

  • jdd


Złoci sponsorzy

Srebrni sponsorzy

  • EPAM
    • j-labs
      • UBS
        • Sii
        • Sponsorzy

          Sponsor Afterparty

          Sponsor Internetu i Gamezone

          • EPAM
          • Patroni medialni

            • Teetbee
            • helion
            • Polish JUG
            • Poznan JUG
            • SDJ
            • naukaJavy.pl
            • pcfoster
            • pcfoster
            • pcfoster