Working in a not strictly TDD group... any tricks

Testing
1

quick background - I work on a small team, 3 full-time engineers. I enjoy, and make every attempt to drive my development with tests, with appropriate coverage at every level. Engineer 2 doesn’t always write tests first, but the coverage at the end of the day is what I like to see. Engineer 3 (the most senior of the bunch) takes pretty much the opposite approach to test coverage than the rest of the team, and would rather do very little testing on the models and most all of the testing in giant controller specs, what would maybe look more like integration specs.

The other day a feature he worked on had a bug which made it to production. While fixing his bug he referred to it as

“a case of tests still passing because of stubbing, but those stubbed methods aren’t the ones that should be used anymore.”

obviously if he were starting with that spec its the first thing that would have changed… but we have to live with the fact that there is no changing anyones mind on behavior on the team.

the question - is basically what can each of us do to better co-exist when we don’t have the luxury of being a team that is more in line philosophically testing-wise?

  1. Is there any thing we can do when writing tests with mocks/stubs to make them a bit more useful to our non-TDD colleagues?
  2. Is there any approach he could have taken, apart from working test first, to help catch lower level tests like this?
2

It sounds like the senior engineer prefers a classicist approach to testing, which until quite recently was very common.

Most Rubyists seem to be on the mockist side, but there are various problems commonly seen with this style such as inappropriate over use of stubbing. The best guide I’ve seen to doing this well is Sandi Metz’s talk The Magic Tricks of Testing. Maybe you could organize a team lunch to watch this together, along with a talk about classicist testing for balance.

Are you using verifying doubles in RSpec? That can help prevent from accidentally stubbing the wrong interface.

I would suggest you let both style of testing co-exis for now, but trying to demonstrate why the mockist approach can be advantageous. Peer review through pull requests can be a great way to demonstrate different approaches.