Tips, Expertise, Articles and Advice from the Pro's for Your Website or Blog to Succeed
In the first article "Building Mancala Game in Microservices Using Spring Boot (Solution Architecture)", I explained the overall architecture of the solution taken for implementing the Mancala game using the Microservices approach.
The DevTeam Project is a library of stories from successful engineering managers around the world about growing, managing, and motivating excellent dev teams. Our mission is to help dev teams learn from great engineering leaders about trends today and what’s shaping their industry. To achieve this we’re going to release a podcast episode and a blog post with highlights from the conversation every other week. In each episode we’re travelling to meet a prominent engineering leader and talk about their unique perspective and insights.
You may also like: Managing Engineers: Minimizing Risk and Surprises [Podcast]
For more stories like that check out The DevTeam Project or subscribe to our podcast using one of the platforms below.
Originally published Jan. 18, 2017
As we write a lot about Agile, CI, and TDD, we had to mention unit testing. This time, we will talk about what unit testing is, why it is part of Agile methodology, and the main benefits of using it.
I'm not a believer in having standards for test coverage. I know teams that require 60%, 70%, or 80% test coverage for their code. I don't like having standards like this because different code has different requirements for testing.
Straightforward code like getters and setters don't really need to be tested. However, more complex code that encapsulates business rules should be tested. When developers do "test after" software development by writing their tests after they write their code, they typically try to find the easiest code to test in order to meet their code coverage standards, but oftentimes this is not the code that we really need to have covered.
When I was young I read a study by TRW done in the '60s that measured the cost of fixing a defect that was detected at different points in the development cycle. If the developer who wrote the defect found it immediately after writing it then we can assign one unit of effort for resolving that defect. If that's true, then it takes something like seven units of effort to resolve the defect during the testing phase, 15 units of effort to resolve the defect just before release, and a whopping 67 units of effort to resolve the defect if it makes it into the hands of the customer. In other words, the cost of fixing defects grows exponentially with the amount of time it took from when the defect was created to when the defect was resolved.
It's always cheaper to fix defects sooner. This is because the longer we wait from when a defect was created, the less we are familiar with it. The vast majority of time and effort in debugging isn't involved in fixing the defect. Some defects do require a significant amount of reengineering but most defects are small problems that can be quickly and easily fixed. What can't be done quickly and easily often is finding the defect in the first place. Much of the time, finding a defect is where we spend most of our effort and once we locate the defect it's usually trivial to fix.
To understand the current and future state of automated testing, we spoke to 14 IT professionals intimately familiar with automated testing. We asked them, "What skills do developers need to ensure their code and applications perform well with automated testing?"
Here's what the respondents told us:
Behavior-Driven Development (BDD), as its name indicates, is not a testing technique, but rather a development strategy (as well as TDD, which is Test-Driven Development). What it proposes is to define a common language for the business and the technical team members, using it at the outset of development and testing, which is why it's important for testers to understand BDD.
I used to think about BDD as an evolution of TDD, but then I realized that it is much more than a simple evolution. It's a different approach that solves a different problem. In TDD, the focus is on the unit test, while in BDD, the focus is testing on a higher level, functional and acceptance testing, as its aim is to comply with the business and not just with the code.
If you're using test-driven development, don't measure unit test code coverage. It's worse than a useless statistic; it will actively lead you astray.
What should you do instead? That depends on what you want to accomplish.
When I was asked to implement TDD/BDD in our work, I searched a lot for a single-page document/site but was not able to find one. Though there are plenty of very good resources available on this topic, I have decided to create a single article to show both of these 2 approaches hands-on.
In Agile development, organizations want to be market ready for new products, features, and functionalities within a very small period of time. But traditional testing methodologies cannot ensure this. To keep up the pace with this rapid development in an Agile environment, a few new design practices for Software Testing were born. We can name a few like ATDD, TDD, BDD, or Integration Testing, but we will limit our discussion to TDD & BDD which are the most used practice nowadays.