Tutorials and resources on how to apply unit testing in software testing
Let’s have a close look into the Red-Green-Refactor cycle and understand the subtleties of each step. When we go down the rabbit hole of Test Driven Design (TDD), we sometimes take too big steps leading us to many failed tests we just can bring back to green without writing a lot of code. We need to take a step back and take the shrinking potion of baby steps again.
This presentation looks at the chasm-crossing potential of Test-Driven Development (TDD) and some related technologies. The aim is that you will still be able to get a good software development job in 2024.
Writing unit tests is easy in theory but could be more difficult in practice. Usually experience helps in getting better at unit testing. In this blog post, Patroklos Papapetrou shares some of his experience in writing Java unit tests.
Test-Driven Development (TDD) has been tattered, torn, twisted, stood on its head, and pounded into an pulp of techno-fetishism. TDD was a game-changer, but the focus in the interceding years has shifted from technique to tools and TDD has been devolving into a lost art.
Successful adoption of unit testing in C++ goes beyond picking a framework: The effectiveness of unit testing is dependent on run-time analysis, static analysis, and other tools to make up the “iron triangle” necessary to get profitable increases in feature velocity and MTBF in the field.
Creating good, effective unit tests in .NET can be harder than it seems. In some cases, the code is designed so that isolating one component from another is easy. However, in most other cases, achieving this isolation is very difficult. First included in Visual Studio 2012, Microsoft Fakes helps you cross this gap.
We all love our tests to speak in the language of business and not in the language of implementation details. In this short presentation I will show how we can get closer to this goal by writing custom assertions with AssertJ.