Tag TDD
To TDD or not to TDD
To TDD or not to TDD? Is this question even relevant or maybe it’s enough to just write tests, no matter before the code or afterward? Let’s see.
Growing Object-Oriented Software, Guided by Tests Without Mocks
This is a review of the Growing Object-Oriented Software, Guided by Tests book (GOOS for short) in which I’ll show how to implement the sample project from the book in a way that doesn’t require mocks to be tested. Growing Object-Oriented Software, Guided by Tests Without Mocks Let me first explain why I’m doing a review of this book. If you read this blog regularly, you probably noticed that I’m pretty much against using mocks in tests.
Styles of unit testing
The topic described in this article is part of my Unit Testing Pluralsight course. In this post, I’ll describe different styles of unit testing and compare them in terms of their value proposition. Styles of unit testing and their value proposition There are 3 major styles of unit testing. The first one is functional, where you feed an input to the system under test (SUT) and check what output it produces:
TDD best practices
Last week, we discussed the differences between stubs and mocks. Today, we’ll talk about some general tips and advice that regard to TDD and writing tests in general.
Stubs vs Mocks
In this article, I’d like to discuss the differences in using stubs and mocks and show how you can abandon using mocks even in the cases where you need to verify that objects interact with each other correctly.
The most important TDD rule
In the previous articles, we discussed what causes the pain while writing unit tests (mocks), and how to make TDD painless (get rid of the mocks). Today, I want to set the groundwork and discuss why mocks actually cause so much pain to us, developers.
How to do painless TDD
Last week, we nailed the root cause of the problems, related to so-called test-induced damage - damage we have to bring into our design in order to make the code testable. Today, we’ll look at how we can mitigate that damage, or, in other words, do painless TDD.
Test-induced design damage or why TDD is so painful
I’m going to write a couple of posts on the topic of TDD. Over the years, I’ve come to some conclusions of how to apply TDD practices and write tests in general that I hope you will find helpful. I’ll try to distil my experience with it to several points which I’ll illustrate with examples.
-
Test-induced design damage or why TDD is so painful
