Run the test a second time, test passes. silently move to the next step.
And then in the end we realize the most important thing was the tests we wrote along the way.
I’ve seen some interesting thoughts on TDD with fail, pass, refactor assumptions. I’m curious if anyone here is writing functional code in order to then make a failing functional test pass i.e. BDD / ATDD. This follows similar logic without the refactor assumption. I’ve seen strong opinions on every side as far as this is concerned. On a team with Dev and QA competencies, I’ve heard a number of devs glad to get QA out of the bottleneck and put their knowledge to better use.
Depends. If I’m working in an existing system and I know what the shape of the thing I’m writing is, then I might write the test first and tdd it out as that process is usually a bit faster for me.
If I’m developing a new feature I’d probably spike out a solution and write an acceptance test to match it, then if I’m feeling pedantic I might throw away the spike code and tdd it back up from scratch but I haven’t done that in a while now.
This all depends on the language and the abstraction layer I’m at.
What if the output is encrypted? Or 34d matrix.
What if the test was testing timing. Or threading. Or error handing?
