Bill Kalligas
F43143823b61e9e40ea092b9eda4c933?d=retro
Ranked 11 in Phase 2 with a weighted final score of 229

About the author

Hello everyone. You want to learn who Vasileios ( or Bill for short ) Kalligas is? Well, he is a bit of a newcomer to the ruby community, but very eager to learn. He is a proud member of the almighty developers team of Pamediakopes.gr, twisting and bending any UI part he can get his hands on, based on the latest market demands and needs.

What he expects to get our of this conference? He actually just wants to participate and get as many good ideas as he can, from all the powerful minds that will attend, while sharing some personal experiences.

35.000 tests and counting!

Some say it’s madness, we answer it’s sanity. Have you ever deployed to production clutching your teeth, crossing your fingers, holding lucky charms or praying to the god of luck to have a successful one? Well.. we haven’t! Why? Because we have made testing a constant and indispensable part of our work.

Quality assurance is a vital part of program development so that the requirements of the final program are achieved, and we think testing is the right way to it. Most of the times we know when something goes wrong really early and we get to change stuff here and there without worrying that the final result will be a tower of cards coming tumbling down.

From all this meddling with the forces of the universe we have come to know some tips and tricks you can use, rabbit holes to avoid and features to keep in mind. Such as:

  • Anti-patterns to avoid
  • When to not write a test
  • Continuous development, continuous testing, continuous integration, continuous development.
  • Know that testing is not a panacea.

Previous Next

Suggestions

  • The proposal author responded 8 months ago

    The aforementioned number of tests refers solely to UI tests running over rspec or cucumber tests for checking javascript functionalities. The number of tests written for models or testing APIs are not included. Main concept behing this presentation is the mentality of writting such tests (or when not to), and some do and dont's we got together over our experience.

  • Fe4dc5ea02ac73b9981bcc549a7a288c?d=retro Daniel Lobato García suggested 8 months ago

    Will this presentation cover how to maintain such a large test codebase?

  • 8495227402a81e6adb37d0992edb75d4?d=retro rilian suggested 8 months ago

    Would be cool if author describe how he got to this situation?

    We had the same experience with monstrous large legacy project - a "mega-rails" one with 2500 tests that run over 25 minutes... We in team have done a series of brainstorming, and made a decision to split it to (now counting 8!) separate REST APIs. This brought success! Each API had own, clear and decoupled tests, and, even though once everything was built we have like 3000 tests in total, they run much faster, most of them are clear and they allow us to look for future challenges.