Fortnightly blog series by RGSoC team — 200OK

Prachi Manchanda

Aug 17, 2017·4 min read

The Summer So Far

This is the third blog in our fortnightly blog series for coala as a part of Rails Girls Summer of Code. We have previously written about writing bears for our project coala and community outreach by the Rails orga team. This blog post shall focus on writing test suites and our experiences with Test Driven Development (TDD)

What is code testing and why is it important?

Unit testing is a software development process in which the smallest testable parts of an application, called units, are individually and independently scrutinized for proper operation. Unit testing can be done manually but is often automated. In simpler words, unit tests help you find bugs in software and make sure the same bugs don’t cause the application to break again.

Testing often seems like a pain to developers and a time consuming job with no actual output except a validation of the development code itself but it is important to realize that testing is as essential for a developer as writing production code.

For one, tests will help you avoid delivering sub standard code. A comprehensive test suite is extremely useful when adding a new feature to ensure that any modifications that you made doesn’t break the existing code base. Further, when refactoring or removing redundant code, tests would be there to ensure that no corner cases are being violated by your changes. Keeping code is clean is incredibly important, especially for vast open source projects.

Secondly, tests help increase code stability. If each commit is tested before deploying, it would ensure that the release version is always a stable build and no users are being impacted by buggy developmental code.

Not just this, tests also supplement your development code by helping new contributors get familiar with the possible tests cases they should keep in mind while making any changes.

coala uses CircleCI, Appveyor and Travis CI for their testing suites and while at times, the broken builds do make us pull out our hair in frustration, we realize the importance of having a robust CI pipeline

When should tests be written?

Test driven development (TDD) guidelines mandate that developers must write test functions before the actual code but most developers prefer writing testing suites retroactively. However in our opinion, it doesn’t actually matter when you write the tests as long as you actually write the tests.

How do you check the quality of your tests?

A common metric for testing the quality of your testing suite is called code coverage. Code coverage basically is a number conveying what percentage of your development code is being covered by your test function. It helps you catch the corner cases you might have missed testing.

coala uses codecov as a part of their development pipeline for checking code coverage and no commit is allowed to be deployed unless it achieves the required code coverage (a minimum of 90% across most projects). We can’t adequately stress the importance of this as it has helped us catch several cases that we had missed while writing test functions.

Is code coverage by itself sufficient?

While code coverage is important and absolutely essential, it is not an adequate metric for checking the quality of test suite. It simple checks for the number of lines of development code that are being tested.

For example: If you are testing a function for finding maximum in an array, you maybe testing the functionality of the function and get 100% code coverage but not test cases such as when the array is out of bounds. Hence, manual testing are also important.

Key Takeaways

• The best practice is to write tests as you go. The developer who writes the development code is the best person for writing the testing suite.
• Ensure maximum code coverage. Keep in mind the 80–20 rule of code coverage (20% of time will be spent in achieving 80% code coverage and 80% of time will be spent in achieving the remaining 20%)
• Manual testing of code is important after automated testing is complete. There is no substitute for peer review and feedback.

If you would like to follow our progress over the summer, you can read our daily logs here or give us a shout on twitter! We’d love to hear from you :)