Test Driven Development, in a nutshell

There’s this big thing in software development; employers are looking for it, our instructors demand it in class, it’s TDD: Test Driven Development.  This process stems from the idea that great programs are built best when we have the right tests in place before hand.  Well-written tests can give a developer a good idea of their final produce as well as let them know if they are on the right track.

As a former teacher, I’m familiar with the concept as teachers use it too.  You write the tests before the lesson plans to ensure that what you’re teaching is aligned with what you want students to master.

I’ve grown a lot in my testing this module. Here are a few tips for getting strong testing going:

• THINK BIG PICTURE: For smaller tasks, think about the final output and write that test first. You can skip it until the end but, at least you know what you are trying to get to.
• THINK SMALL PICTURE: For larger projects or ones where the steps needed to get the final output are not clear, think small.  Think about the smallest first step and write a test for that.
• ADD A STEP: Increment your tests upward, think about the next step necessary and write a test for that.
• AVOID REDUNDANCY: Don’t over do it. Think of the rule of none, one and some.  If you are testing for one or two items that’s fine, but there probably is no difference between two and four inputs, so multiple tests that test the same thing are not necessary.
• EDGE CASES: Think about Edge Cases. What would happen if nothing was entered? What if the input was a string instead of a float? What if data is missing/ incorrect?
• TDD CODING: Follow this format for coding: Write the test, unskip it, run it, write the code afterward
• At the end of your program use testing aides like simple cov, Code Climate or Travis CI to detect untested areas.
• Don’t trust these programs completely, look through each line of code as well and make sure each method is tested.
• One final check is to comment out a particular method or line and see if a test breaks.  If it doesn’t, you either have code you do not need or you need to write another test.