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

Question

Hello, 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 :)

Answer 1

Store the unit tests in a parallel version control and only submit the code to the central system. He will review your code without unit tests and you still get to benefit from them ...

Additionnaly, I suggest using one of the distributed version control, you get to play with a new, fun toy, and when one of your other co-workers wants to try, he can easily embrace and extend your test suite.

Edit To clarify following comments:

I am suggesting he sets up a local source code repository for his unit tests. The code itself would still be synched with the managed repository (through the normal submission process just not submitting the tests along with the code).

He could also keep the unit tests he feels are useful on his hard drive and it wouldn't change anything, the same way any dev I know has a few "tool" files around for various purposes.

The idea is that working with unit tests, he can hope for his bug ratio to be lower than the others. It can help when arguing about this kind of thing with his tech lead. As long as he completes assigned work on time I don't see why he couldn't work as he sees fit.

Answer 2

In few minutes you should be getting some answers mostly favorable to you. Show this thread to that person who is resisting the code. :)

Answer 3

The most important thing in a development team is to stick to the standards, even if you dont agree with the standards. If everyone does their own thing, then there is no point in having standards.

You could keep the unit tests for your own personal satisfaction/confidence. Maybe one day you can demonstrate that your approach has stop a bug from reoccuring or benefitted the team in some way and then it may be easier to get your point accross.

One day you will be the guy setting the standards and then some people will disagree with you. Then you can tell them this story.

Disclaimer: I use unit tests when appropriate and anyone who works for me will be encouraged to as well.

Answer 4

I'm sorry but you'll have to adapt yourself to the team. You'll have to speak them often about unit test, you can'nt convince them in one day.

My chief didn't know anything about oop and he was still programing in c#, now in convinced him to use constructor, maybe in a few month he'll do private field/ method instead of static method.

adapt yourself.

Answer 5

If the team is not experienced in maintaining a unit testsuite, then they have a problem, but you will hardly be able to solve it if he is more important in the company than you are.

Answer 6

I'm a lazy bastard who doesn't write anywhere near enough unit tests, but I'm not idiotic enough to reject unit tests when my guys go to the effort of writing them. You could try to work within the confines of stupid management, but unless there's some hope that this guy is going to disappear from the scene soon, I suggest you find another team.

Answer 7

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.

Answer 8

Rename your Unit Tests "en camera functional tests".

EDIT: More practically, if you cannot overcome the human element, you could maintain your unit tests in a small, private, parallel repository. Unpack them when you develop or maintain, run them, update them, then put them away until next time.

Answer 9

Interesting that the code was rejected because of unit tests. Had you left them out of the code you submitted for acceptance, would it have been accepted? If that is the case, you just keep doing unit tests and keep on churning out production code that passes those unit tests. If your tests are good ones, they'll only improve the production code you turn in. The "overhead" of writing the unit tests is not that much - certainly when compared to finding bugs downstream.

That said, you cannot walk into a new group and expect to change the culture of the group overnight - this just doesn't happen typically. Better that you keep up with your good practices and submit the code that passes your tests. In time, your coworker might come around or the rules might change. People are reluctant to change until they see the benefits.

If your code doesn't meet some other standard set by the group, you'll need to address that, of course.

Answer 10

Have your team lead read this paper (pdf), (which you can find neatly digested in this blog post), and see if he changes his mind.

Now, one study doesn't prove anything, but there is one very intriguing take-away paragraph:

We found that test-first students on average wrote more tests and, in turn, students who wrote more tests tended to be more productive. We also observed that the minimum quality increased linearly with the number of programmer tests, independent of the development strategy employed.

In other words, better tests, better code. Period. (This squares with my experience, and the experience of countless other developers I've worked with.)

If you can't get this guy to change his mind, then look for work elsewhere -- you've ended up on one of those loser teams where those in charge are impervious to learning something new. Not good.

EDIT: there are dozens of studies showing the effectiveness of TDD. Try here and here for more.

Answer 11

Keep writing those tests, but avoid writing trivial tests. Maybe with a trivial test you think you can educate others, but they might see it as proof of being a waste of time. Try to fix bugs by writing a test to reproduce the problem and do a presentation about what you did to the team. Try not to sell unit testing as the new religion, but try to explain why this is the way you work. Spend your energy on convincing the other team members first.

At some point they will notice you can make big changes to the implementation of your code without regressing.

Answer 12

One of the good advices I got during a university lecture on software quality:

If you get in a team/company where they really don't know how to make software. Try to help them improve (accept there isn't one good way, but not trying is not the way). Come up with good arguments (such as: my code has less bugs and takes the same amount of time to write?). If you can't change the company/team: Don't stay, start looking for a new job, with this company or another.

Answer 13

It sounds to me like he is refusing to check in sources that contain code to perform unit tests, right?

The simple solution to that is to not try to check in your unit test code. You can still write it and perform unit tests, but keep it separate. If you want it revision controlled, keep your own separate repository for your unit tests.

This is how I've done it most of my 20ish year career. I think I've only ever worked on one program that officially tracked unit tests like your old group did.

Answer 14

Unit tests have costs, not just benefits. From http://www.joelonsoftware.com/items/2009/09/23.html:

Zawinski didn’t do many unit tests. They “sound great in principle. Given a leisurely development pace, that’s certainly the way to go. But when you’re looking at, ‘We’ve got to go from zero to done in six weeks,’ well, I can’t do that unless I cut something out. And what I’m going to cut out is the stuff that’s not absolutely critical. And unit tests are not critical. If there’s no unit test the customer isn’t going to complain about that.”

From: http://www.codinghorror.com/blog/2005/04/good-test-bad-test.html

My main problem at the moment with unit tests is when I change a design I get a stack of failing tests. This means I'm either going to write less tests or make fewer big design changes. Both of which are bad things.

Answer 15

I'm going to propose a less dramatic version of John Feminella's answer.

Talk to the person in question but don't make a big song and dance about it. Certainly don't say "why don't you like me doing something which makes my code better", this is challenging his knowledge and given that many developers are quite sensitive about implied criticism, he may just tell you to get lost.

Instead I'd first clarify "did you only fail the review because i included this test code?" Then say "I find my productivity is higher when I write tests, what is the problem me checking in tests"

Answer 16

On the flip-side, the reason unit tests may be rejected by the reviewer could be:

• Likely, rules apply to all code in the project
• This means unit tests means a lot more code to review
• Unit tests may not be written in a way meeting general review/coding standards

Especially in C++, I imagine your tests kind of mix in with the main application code, since no unit testing setup exists in the project already. In which case it might make the code harder to follow.

Answer 17

This doesn't really address your question, but you didn't mention whether you're getting code coverage.

Functional testing plus code coverage can be effective in demonstrating code correctness and may have been popular when you manager was coming up through the ranks.

The main problem is that it's a lot of effort and not very practical when your code is still in flux.