As I take my first step towards my journey in Software Quality Assurance and Testing I dive into Unit Testing. After searching the web found a really good podcast named “Unit Testing With Test Driven Development” by Beej Burns this podcast is about Unit Testing and focuses most on Test-Driven Development (TDD). I will be using this podcast to help me write this blog.
The Following Q&A are the Question asked in the podcast and the guest answer. The answer I am writing are summarized in my own words but originally derived from the guest on the podcast. Also I am not doing all the Q&A just the ones I found interesting and liked how the guest answer the question. If you want to hear the original question and answer visit the podcast site: https://completedeveloperpodcast.com/episode-140/, Lets start.
What is Unit Testing?
Unit Testing is the ability to test in isolation. That is to simply test an application without affecting the rest of the other test.
Why is Unit Testing important?
We use unit testing to make sure each unit performs as intended. Unit testing is important because it minimizes the risk of error in your software, but it also forces you to have better code structure. It also allows major changes in your code to happen at a lower risk. Another reason it is important is because it allows new developer to understand your software structure.
*Note that naming convention is very important so developers can understand what is being tested.*
What is the point of Test-Driven Development (TDD)?
The point of TDD is doing the right thing without making a mess. That is short iteration cycle reassuring that you and your application are doing the right thing.
According to one of the guests when writing Test-Driven Development there are 3 stages/steps:
- Red cycle to see test fail
- Green phase when you make the test pass
- Refactor production code and test code.
The idea of TDD is to build the test before the code.
Other benefit for TDD other than code in an organized level is:
- Reduces the overall bugs and make bug resolution quicker.
- Less down time.
- Better requirement
- Can find problems with just running the test which it shows where code went wrong.
What are some of the things people get wrong about unit testing and TDD?
Testing your test too close to your implementation. “Test should represent the business rules not how you decided to implement the business rule. That way when you go and change stuff later on like the implementation. You want to refactor and remove thing into a different class. This doesn’t break what your test does because you will be restructuring how it is doing it”.
How do you manage complexity on a unit test, and how do you structure your overall testing projects?
“Form an overall method uncle bob (Robert Martin) suggest only having method that are five lines or less in size”. The guest that answer this question take Robert Martin suggestion to heart. He goes on and explains that if a method has more then five lines then he’ll brake it down into more than one method. If a class has more than five method then he’ll brake that down into more than one class. If a folder has more then five class than he’ll brake that down into more than one folder. If a project has more then five folder he’ll consider braking it down into more than one project. He goes on and say that he will do the same exact thing when testing except he doesn’t care much about the line length because most test case are usually 3-4 lines long. He has the arrangement where he set up the pre-content of the test and then have the action are 1-2 lines. These tests are pretty small to start with but within a test class he won’t have more than five things overall that he is testing within a test class, no more then five unit, and no more than five logical assertion which tends to reduces the size of any one thing within a test project.
What are some good practices you can use to make sure your test is maintainable on the long run?
- “Don’t forget to refactor your test, because your test suit is just as important as your production code”.
- “Remember you are testing small unit or small pieces that should have never enter connective dependency so that you feel comfortable substituting a mock, spy, or fake implementation. Be careful not to test your fake, mock, or spy.”
- “Where ever the code end that’s where the test should end”.
- “Make sure we abstract all third-party code”.
I will wrap this up by saying unit testing is a very important skill to have no matter what. It helps in creating clean code and reduces the risk of error. Unit testing allows software developers to make large changes in the software code at a minimal risk rate and it allows code structure to be understandable by new developers. One thing to note is when creating unit test and developing software you must make sure to have good naming convention. When developing software, its best to start with writing the test first.
My name is Yesenia Mercedes-Nunez and this has been YessyMer in the World Of Computer Science, thank you for your time until next time.