I’m pretty good at cooking, if I do say so myself. That may be because I only cook a handful of dishes, or that may be because I’m extra attentive to the ingredients, the taste, and am obsessive about the details.
But, and this is an important distinction: I’m not a chef. I cannot make those beautiful and delicious meals chefs can, nor would I be able to if someone asked.
In the same vein, I can write tests, and I write lots of tests through TDD; but I’m not QA. My tests are documentation, bounds exploring, code that reflects decisions made, and an early warning system for potential problems in the architecture, but, my tests are not the tests a QA person would produce, and confusing the two would have the same effect as confusing my cooking abilities for a chef’s.
In case I haven’t hit the point hard enough home, let me say it outright:
QA has a very important job, a job that keeps most software afloat without the business even knowing it. All the TDD in the world can’t supplant the ability of QA to head off danger, and just saying “Developers can write tests too” doesn’t make Developers QA.
This is a very important lesson that some companies forget, and the markets remind them.
This post comes from my daily email list. If this sort of content appeals to you, you can sign up for the daily email below.
It’s amazing how many decisions we make in the course of developing a feature:
– How should this work?
– what does a developer need to call this method?
– What other parameters should we add?
– What should logging look like?
– How do we add new capabilities to this feature?
– Where should we store settings for this feature?
and on, and on, and on.
The cognitive load itself can be a bit heavy, and then there’s what can happen when you mix the features together. It starts to look like spaghetti if you aren’t careful.
One of the wonderful things about TDD is that it can help you make those decisions and it can show you the impact of those decisions far faster than implementing logging or setting storage or how parameters get added if you hadn’t had tests in place.
Without TDD, you have to implement a feature in at least two out of three layers of your application: either UI and Code, or Code and Database. With TDD, you take that time and you cut it down to just code.
That’s pretty remarkable, and can help you make decisions faster.
I’m covering this (and more) at the free webinar on March 5th, titled “Intro to TDD For .NET”. We’re not going to spend much time on the mechanics of TDD, rather we’re going to spend the time showing how TDD can actually help you. If that’s interesting to you, sign up here.
There’s a lot of cool stuff out there that I’ve never had a chance to work with, and having just finished watching all of the .NET Conf 2020 videos(!), I’m excited to see what’s on the horizon and what’s available now. So I should probably just start suggesting this stuff when I’m working on a team, right?
Wrong. Dead wrong. As wrong as a person can be.
The team, any team has a culture, and that culture, the business context, the political context, the financial context, and the social context dictate how much a team can take on and whether the team is willing to learn something new. One of the many mistakes I’ve made is to try to show I can help out by suggesting new things to try; and that’s never worked well for me in situations where all those contexts weren’t lined up in my favor.
Sometimes people say no not because something can’t be done, but because something can’t be done given the current culture, political, business, or social context on the team. Recognizing the difference will go a long way to helping your team grow and thrive.
P.S., if the team is pushing back with ‘no’ a lot (an unenthusiastic ‘yes’ is also a no), it’s worth examining those contexts; what’s going on? What’s keeping the team from being engaged? The answers may surprise you.
Reactive forms are fun in angular, and fun here means “not fun”.
They’re ‘fun’ because they’re meant to be testable; and easier to reason about, and they are… so long as you don’t do anything advanced, like form controls interacting with each other; or FormArrays, or anything like that.
Or, if you aren’t into Angular; have you ever tried to test an ASP.NET MVC (not .NET Core) controller?
There’s about 12 lines of mocking you have to do to unit test it; and it is a nightmare.
There are those that try to force testing into those situations; as if it’s a good idea to poke yourself in the eye.
Software is built by humans; and sometimes those humans didn’t try a ‘test first’ approach to their code. Trying to isolate and test in these situations means taking on a lot of brittleness by using Mocks and Stubs; and is that really the best use of our time?
There are times that if it hurts you should ‘do it until it doesn’t hurt’, but this isn’t one of those times. If you don’t have control over a library or framework and you find yourself encountering lots of pain trying to write tests for something that interacts with that library, maybe the best answer is… don’t.