What should I do when a co-worker rejects my commits because they contain unit tests?

Question

I've moved from one team to another in same company. In old team (hardcore c++) we did lots of unit testing. In my new team (also c++) they do functional testing instead. During review they reject my code because of unit tests. Most of the team is interested in learning something new but not the guy who is VIP and has legacy developer approach. He has to accept code before commit. He resists the change. Advice?

// update: I'll inform in this topic what happened with my quest but please understand it's a big company, it takes time. Just to clarify, tests I do are fine and it always worked in other teams. I'm not new to this. From time to time I need to brake dependencies cause code it plain crap. In C++ you sometimes have to. That may introduce change in prod code just because of test. I believe having unit test justifies this kind of simple changes. It's better to have it than not.

// update2: Thanks for lots of good advice, clearly there is no silver bullet here :( Most of the team is convinced but 2 senior (15y+) devs are still opposing. I will give short talk on this the rest of my team will support me so I hope that those guys will just agree :) To relax a bit I've started learning ruby :)

question from:https://stackoverflow.com/questions/2607481/what-should-i-do-when-a-co-worker-rejects-my-commits-because-they-contain-unit-t

Answer 1

You've just encountered the hardest software problem of all: people. While I'm hesitant to second-guess your boss without some more context (for example, is this really the complete testing picture?), an outright rejection of your code solely because you included unit tests is a questionable practice at best.

The most sensible route is have a one-to-one chat with this person so that you understand his position. You describe your boss as resistant to change, but usually people aren't so black and white. For instance, perhaps he views the volume of code you're submitting as risky given your new status on the project, not understanding that your unit testing enables you to write more code because you can have higher confidence in it. So I'd give him the benefit of the doubt, and have a heart-to-heart first.

Here are some questions to ask during your conversation:

• What are your thoughts about unit tests? How do they fit into our overall testing strategy?

• What are your issues with the unit tests I've been submitting? Are they deficient or lacking in some way? Are you okay with the unit testing itself, but would prefer that my code be organized differently?

• Why should all of our code be tested at the functional level?

• Are all unit tests bad or inappropriate for our project?

• How do you plan to discover problems associated with specific inputs to methods when those conditions are more complex to replicate at higher interface levels?

• If you have a specific objection to unit tests being checked in, is there any objection to using unit tests locally so that I can at least verify my own code?

If you feel that you now understand his position and it's untenable with the way you want to write software, you have a different question to ask yourself: Do you enjoy the work enough to stay on the team in spite of the professionally questionable practices, or is it time to start looking elsewhere?

Conversely, if you feel that you now understand why the rule is there and you think it's sensible in light of the overall context of the project, then huzzah! You avoided a potential crisis by handling yourself professionally, you get to stay with your new team, and you get to go back to the fun part: software development.

---

Edit: I really can't agree with some of the posts in this question telling the OP to adapt himself to the team. Standardization of practices is only good when the team buys into the practice. Instead of telling the OP to suck it up and fall in line, we should be encouraging him to understand why the rule is in place, so that he can evaluate whether it makes sense on its own merits.

The manager also has some explaining to do so that he can help the OP see things his way. Sure, not everybody will agree with managers all the time. I've led projects or teams, and made my share of decisions that couldn't please everybody, but I always tried to make them with input from everyone first, so that I could arrive at the best decision. In my opinion, enforcing a set of "standards" by managerial fiat without considering the impact to the team and ignoring alternative suggestions makes you a bad manager, not a good one.