Search Results

Classic TDD suggests writing a single example, then writing the code that makes the example work. … Of course, “real” TDD is not common. Your specific organization might indeed delegate some responsibilities to a dedicated QA role, but that would have nothing to do with TDD itself. …

On a social level, it is difficult to enforce TDD. TDD is a possible structure for a personal productivity cycle, and is not really applicable for a whole team. … But this is just about testing, not about TDD. …

In your TDD red–green–refactor cycle, you should add one example data set at a time. Combining multiple test cases into a parametrized test would be part of the refactoring step. …

The flip side of this is that the TDD tests should be created in really small steps as well, so that a tiny change is sufficient to make them pass. … So I would recommend doing micro-TDD as an exercise, not necessarily as part of everyday work. On the other hand, tooling can be improved. …

The scenario should be set up in the Given step. This involves mocking parts of the system. However, a mock might be used in the When step when that's part of the action. When reading your two scenari …

TDD does absolutely not replace defensive programming. Instead, you can use TDD to make sure all defences are in place and work as expected. … In TDD, you are not supposed to write code without writing a test first – follow the red–green–refactor cycle religiously. …

The code snippet you have shown is an excellent unit test, provided that the unit under test is an abstract part combinator, and does not have a more concrete responsibility within the problem domain …

TDD and BDD are not primarily about testing the software, but also about finding out what to build. … For example, the TDD red-green-refactor cycle starts by us thinking about a new atomic requirement for a piece of software, then writing a test case for that requirement, and then implementing it. …

TDD is neither clearly black-box or white-box. … But when we look at the information flow, TDD tests are not derived from the source code, but from external requirements. Therefore, TDD is more black-box-like. …

You don't have to unit-test everything. Relying on integration or E2E tests is fine, especially when the aspect you want to test is at the interface of two components. Here, you have the interface bet …

Refactoring is cleaning up a piece of code (e.g. improving the style, design, or algorithms), without changing (externally visible) behavior. You write tests not to make sure that the code before and …

Despite the other answers to this question, there is in fact a lot of behaviour in this method, and therefore a lot of things that could go wrong if we don't test them. Here are the cases I would chec …

Tests are code, and as such common best practices should be applied: repeated code should probably be extracted into a method. However, this has to be balanced: Tests should be very, very obvious, m …

The terms “unit testing” and “component testing” are not defined universally, and different people hold different notions what these terms mean precisely. However, they are generally understood to be …

Not all tests are equal. Some have value, and some are a waste of time. Especially for user interface details, it's possible to get carried away and write automated tests where this isn't helpful. H …