On Veszpremi Technology Meetup I presented my experiences of test driven development. Test driven development nowdays is getting more used technique to occur problems in long-running projects. Now I want to write more about this technique and describe why and for whom it is so good. (on the right picture you can see Mixer on the Veszpremi Technology Meetup, I have no snap about me)

Newbie developers without less practiced knowledge write short programs for fun, containing 5-10k lines maximum. They check the implemented features just after adding some lines of code. It’s an easy method for smaller home used scripts and I guess this is the best solution to implement ideas fast. For companies with high responsibility it’s not an option.

Automated test system is a must for software companies nowadays. The later it’s steped by the company, the harder adding functionality to the system without any side-effect. Without elaborated test suites the bugs will appear in release tests, when nobody counts it on. Why? Because your team worked on a specified part of the software (added functionality the a module), so they didn’t verify all the components after each code change. To test everything after any code change would be impossible, I hope you feel it! In release test they check all the functionality together, and they must find release critical defects when your customer is in the door.

The other problem with manual tests is the developers are being afraid to make bigger refactoring in the source code, because it needs much testing time and tester resource. If you are a programmer, you must know there’s no perfect design, and there’s no perfect customer whose ideas are the same from the beginning till the end of the project.

Test driven development (TDD) originates from Kent Beck, who created the JUnit for Java developers with Eric Gamma too. Good to know, it’s a developing process and not a test strategy. TDD says first write the tests that will check the functionality or your object’s behavior, and just implement the feature afterwards. It’s a very hard process for programmers who has written many programs in his life.

Why is it so good? Your task is to complete your customer’s requirements. If you write the code first, the software’s structure will lead you and the result won’t meet with your customer’s expectation. If you write your tests first, you don’t see the structure of the codebase, so it doesn’t affect on you. You can be creative and you can turn over the problem.

After the specification is ready, document it! Your tests are your documentation. Your tests must be understandable and easy to read. Do your tests fail? No matter, this is your goal!

Make your tests green! Implement only as much as enough to make your testcases green. If the result is not acceptable for your customer, then your tests don’t cover everything. Extend your tests with new cases, and implement it. It needs many iterations, but it’s a very good game!

When your tests are green, refactor your code! Follow Robert C. Martin’s clean code directives, your tests ward your ass! I guess this is the best part of the process. Change the structure of the code, extract code blocks to private functions, make your code easy readable! Don’t forget to write your tests (in this phase usually these are your unit tests) before extract something! Write new test, refactor, test again, and take another round!

When your code reaches your quality level, document it and integrate the result to mainline.

Why is it necessary to write your tests before? You can trust in your tests while they cover fully your code. If you write your test first and write as much code as it needs, you can reach the full coverage. When you write your code before testing, it will be harder to test it. Therefore you will skip it or just forget something to cover, and later you will have problems.

Make the long story short, I share my presentation with you guys: