If you systematically perform code reviews before allowing a developer to commit the code, well, your problem is mostly solved. But this doesn't seem to be your case, so this is what I recommend:
Talk to the developer. Discuss the consequences for others in the team. Most developers want to be recognized by their peer, so this might be enough. Also point out it is much easier to fix bugs in the code that's fresh in your mind than weeks-old code. This part makes sense if you have some form of code owneship in place.
If this doesn't work after some time, try to put in place a policy that will make commiting buggy code unpleasant for the author. One popular way is to make the person who broke the build responsible for the chores of creating the next one. If your build process is fully automated, look for another menial task to take care of instead. This approach has the added benefit of not pinpointing anyone in particular, making it more acceptable for everybody.
Use disciplinary measures. Depending on the size of your team and of your company, those can take many forms.
Fire the developer. There is a cost associated with keeping bad apples. When you get this far, the developer doesn't care about his fellow developers, and you've got a people problem on your hands already. If the work environment becomes poisoned, you might lose far more - productivity-wise and people-wise - than this single bad developer.
As a developer who rarely tests his own code, I can tell you the one thing that's made me slowly shift my behavior...
Visibility
If the environment allows pushing code out, waiting for users to find problems, and then essentially asking "How about now?" after making a change to the code, there's no real incentive to test your own stuff.
Code reviews and collaboration encourage you to work towards making a quality product much more than if you were just delivering 'Widget X' while your coworkers work on 'Widget Y' and 'Widget Z'
The more visible your work is, the more likely you are to care about how well it works.
Code review. Stick all of your dev's in a room every Monday morning and ask them to bring their most proud code-based accomplishment from the previous week along with them to the meeting.
Let them take the spotlight and get excited about explaining what they did. Have them bring copies of the code so other dev's can see what they're talking about.
We started this process a few months ago, and it's astonishing to see the amount of sub-conscious quality checks that take place. After all, if the dev's are simply asked to talk about what they're most excited about, they'll be totally stoked to show people their code. Then, other dev's will see the quality errors and publicly discuss why they're wrong and how the code should really be written instead.
If this doesn't get your dev to write quality code, he's probably not a good fit for your team.
Make it part of his Annual Review objectives. If he doesn't achieve it, no pay rise.
Sometimes though you do just have to accept that someone is just not right for your team/environment, it should be a last resort and can be tough to handle but if you have exhausted all other options it may be the best thing in the long run.
Tell the developer you would like to see a change in their practices within 2 weeks or you will begin your company's disciplinary procedure. Offer as much help and assistance as you can, but if you can't change this person, he's not right for your company.
使用 Cruise Control 或类似工具，您可以使签入自动触发构建和单元测试。 您仍然需要确保他添加的任何新功能都有单元测试，您可以通过查看他的签入来做到这一点。 然而，这是一个人的问题，因此技术解决方案只能到此为止。
Using Cruise Control or a similar tool, you can make checkins automatically trigger a build and unit tests. You would still need to ensure that there are unit tests for any new functionality he adds, which you can do by looking at his checkins. However, this is a human problem, so a technical solution can only go so far.
Make him "babysit" the build, and become the build manager. This will give him less time to develop code (thus increasing everyone's performance) and teach him why a good build is so necessary.
Enforce test cases - code cannot be submitted without unit test cases. Modify the build system so that if the test cases don't compile and run correctly, or don't exist, then the entire task checkin is denied.
Intro
What shall we do with a drunken sailor, (3×)
Early in the morning?
Chorus
Wey–hey and up she rises, (3×)
Early in the morning!
Verses
Stick him in a bag and beat him senseless, (3×)
Early in the morning!
Put him in the longboat till he’s sober, (3×)
Early in the morning!
等等。用“马虎的开发人员”代替“醉酒的水手”。
Here are some ideas from a sea shanty.
Intro
What shall we do with a drunken sailor, (3×)
Early in the morning?
Chorus
Wey–hey and up she rises, (3×)
Early in the morning!
Verses
Stick him in a bag and beat him senseless, (3×)
Early in the morning!
Put him in the longboat till he’s sober, (3×)
Early in the morning!
etc. Replace "drunken sailor" with a "sloppy developer".
根据您使用的版本控制系统的类型，您可以设置签入策略，强制代码在允许签入之前通过某些要求。 如果您使用的是 Team Foundation Server 这样的系统，它使您能够指定签入的代码覆盖率和单元测试要求。
Depending on the type of version control system you are using you could set up check-in policies that force the code to pass certain requirements before being allowed to check-in. If you are using a sytem like Team Foundation Server it gives you the ability to specify code-coverage and unit testing requirements for check-ins.
You know, this is a perfect opportunity to avoid singling him out (though I agree you need to talk with him) and implement a Test-first process in-house. If the rules aren't clear and the expectations are known to all, I've found that what you describe isn't all that uncommon. I find that doing the test-first development scheme works well for me and improves the code quality.
Peer programming is another possibility. If he is with another skilled developer on the team who dies meet quality standards and knows procedure then this has a few benifits:
With an experienced developer over his shoulder he will learn what is expected of him and see the difference between his code and code that meets expectations
The other developer can enforce a test first policy: not allowing code to be written until tests have been written for it
Similarly, the other developer can verify that the code is up to standard before it is checked-in reduicing the nmber of bad check-ins
All of this of course requires the company and developers to be receptive to this process which they may not be.
It seems that people have come up with a lot of imaginative and devious answers to this problem. But the fact is that this isn't a game. Devising elaborate peer pressure systems to "name and shame" him is not going to get to the root of the problem, ie. why is he not writing tests?
I think you should be direct. I know you say that you've talked to him, but have you tried to find out why he isn't writing tests? Clearly at this point he knows that he should be, so surely there must be some reason why he isn't doing what he's been told to do. Is it laziness? Procrastination? Programmers are famous for their egos and strong opinions - perhaps he's convinced for some reason that testing is a waste of time, or that his code is always perfect and doesn't need testing. If he's an immature programmer, he might not fully understand the implications of his actions. If he's "too mature" he might be too set in his ways. Whatever the reason, address it.
If it does come down to a matter of opinion, you need to make him understand that he needs to set his own personal opinion aside and just follow the rules. Make it clear that if he can't be trusted to follow the rules then he will be replaced. If he still doesn't, do just that.
One last thing - document all of your discussions along with any problems that occur as a result of his changes. If it comes to the worst you may be forced to justify your decisions, in which case, having documentary evidence will surely be invaluable.
Stick him on his own development branch, and only bring his stuff into the trunk when you know it's thoroughly tested. This might be a place where a distributed source control management tool like GIT or Mercurial would excel. Although with the increased branching/merging support in SVN, you might not have too much trouble managing it.
EDIT
This is only if you can't get rid of him or get him to change his ways. If you simply can't get this behaviour to stop (by changing or firing), then the best you can do is buffer the rest of the team from the bad effects of his coding.
If you are at a place where you can affect the policies, make some changes. Do code reviews before check ins and make testing part of the development cycle.
Put your developers on branches of your code, based on some logic like, per feature, per bug fix, per dev team, whatever. Then bad check-ins are isolated to those branches. When it comes time to do a build, merge to a testing branch, find problems, resolve, and then merge your release back to a main branch.
Or remove commit rights for that developer and have them send their code to a younger developer for review and testing before it can be committed. That might motivate a change in procedure.
Are you referring to writing automated unit test or manually unit testing prior to check-in?
If your shop does not write automated tests then his checking in of code that does not work is reckless. Is it impacting the team? Do you have a formalized QA department?
If you are all creating automated unit tests then I would suggest that part of your code review process include the unit tests as well. It will become obvious that the code is not acceptable per your standards during your review.
Your question is rather broad but I hope I provided some direction.
I would agree with Phil that the first step is to individually talk to him and explain the importance of quality. Poor quality can often be linked to the culture of the team, department and company.
Make executed test cases one of the deliverables before something is considered "done."
If you don't have executed test cases, then the work is not complete, and if the deadline passes before you have the documented test case execution, then he has not delivered on time, and the consequences would be the same as if he had not completed the development.
If your company's culture would not allow for this, and it values speed over accuracy, then that's probably the root of the problem, and the developer is simply responding to the incentives that are in place -- he is being rewarded for doing a lot of things half-assed rather than fewer things correctly.
Make the person clean latrines. Worked in the Army. And if you work in a group with individuals who eat a lot of Indian food, it wont take long for them to fall in line.
I'd be tempted to suggest elaborating a bit on what you've tried and what results you got as this may have changed a bit but here are my initial suggestions:
Is it any tests or comprehensive tests? Some may code blindly and do zero tests, but this is rather rare, IME. Usually there are some tests done but not enough to cover most of the cases that would be comprehensive testing.
Group dynamics may help. I'd assume he is part of a team and that the team's view may be of some help here. In a way this is trying to get peer pressure which is usually a bad thing but sometimes it can be used in good ways.
How well spelled out were the warnings? In a way this can seem childish but there is a chance that what you think of as testing may not be the same as his. Do you want nUnit tests, an excel spreadsheet, logs from his computer, or something else as proof of the existence and use of tests? From what you've described there isn't anything to confirm that he did understand what you meant, was going to use tests and provide evidence of doing so.
Check-in policy question. Some places, such as my current workplace, encourage committing often which can mean that one does commit code without tests. Is there a known, accepted and well-followed policy where you are? That's another aspect here.
发布评论
评论（30）
如果你可以进行代码审查——那是一个完美的地方。
我们需要在合并到迭代主干之前进行审查，因此通常所有内容都会被捕获。
If you can do code reviews -- that's a perfect place to catch it.
We require reviews prior to merging to iteration trunk, so typically everything is caught then.
如果您在允许开发人员提交代码之前系统地执行代码审查，那么您的问题就基本解决了。 但这似乎不适合您的情况，所以这是我的建议：
If you systematically perform code reviews before allowing a developer to commit the code, well, your problem is mostly solved. But this doesn't seem to be your case, so this is what I recommend:
作为一个很少测试自己代码的开发人员，我可以告诉你一件事让我慢慢改变我的行为......
可见性
如果环境允许将代码推出，等待用户发现问题，然后本质上是问“现在怎么样？” 对代码进行更改后，就没有真正的动力去测试自己的东西了。
代码审查和协作会鼓励您努力制作高质量的产品，而不是您只是交付“Widget X”，而您的同事则在“Widget Y”和“Widget Z”上工作。
您的工作越引人注目，您就越有可能关心它的运作效果如何。
As a developer who rarely tests his own code, I can tell you the one thing that's made me slowly shift my behavior...
Visibility
If the environment allows pushing code out, waiting for users to find problems, and then essentially asking "How about now?" after making a change to the code, there's no real incentive to test your own stuff.
Code reviews and collaboration encourage you to work towards making a quality product much more than if you were just delivering 'Widget X' while your coworkers work on 'Widget Y' and 'Widget Z'
The more visible your work is, the more likely you are to care about how well it works.
代码审查。 每周一早上将所有开发人员集中在一个房间里，并要求他们将上周最自豪的基于代码的成就与他们一起参加会议。
让他们成为众人瞩目的焦点，并兴奋地解释他们所做的事情。 让他们带来代码的副本，以便其他开发人员可以看到他们正在谈论的内容。
我们几个月前开始了这个过程，令人惊讶的是，我们进行了大量的潜意识质量检查。 毕竟，如果开发人员只是被要求谈论他们最兴奋的事情，他们就会非常兴奋地向人们展示他们的代码。 然后，其他开发人员将看到质量错误并公开讨论为什么错误以及应该如何编写代码。
如果这不能让您的开发人员编写出高质量的代码，那么他可能不适合您的团队。
Code review. Stick all of your dev's in a room every Monday morning and ask them to bring their most proud code-based accomplishment from the previous week along with them to the meeting.
Let them take the spotlight and get excited about explaining what they did. Have them bring copies of the code so other dev's can see what they're talking about.
We started this process a few months ago, and it's astonishing to see the amount of sub-conscious quality checks that take place. After all, if the dev's are simply asked to talk about what they're most excited about, they'll be totally stoked to show people their code. Then, other dev's will see the quality errors and publicly discuss why they're wrong and how the code should really be written instead.
If this doesn't get your dev to write quality code, he's probably not a good fit for your team.
使其成为他的年度审查目标的一部分。 如果他达不到目标，就不会加薪。
有时，尽管您确实必须接受某人不适合您的团队/环境，但这应该是最后的手段，并且可能很难处理，但如果您已经用尽了所有其他选择，从长远来看，这可能是最好的事情。
Make it part of his Annual Review objectives. If he doesn't achieve it, no pay rise.
Sometimes though you do just have to accept that someone is just not right for your team/environment, it should be a last resort and can be tough to handle but if you have exhausted all other options it may be the best thing in the long run.
告诉开发商您希望看到他们在两周内改变做法，否则您将开始对公司进行纪律处分。 提供尽可能多的帮助和帮助，但如果你不能改变这个人，他就不适合你的公司。
Tell the developer you would like to see a change in their practices within 2 weeks or you will begin your company's disciplinary procedure. Offer as much help and assistance as you can, but if you can't change this person, he's not right for your company.
使用 Cruise Control 或类似工具，您可以使签入自动触发构建和单元测试。 您仍然需要确保他添加的任何新功能都有单元测试，您可以通过查看他的签入来做到这一点。
然而，这是一个人的问题，因此技术解决方案只能到此为止。
Using Cruise Control or a similar tool, you can make checkins automatically trigger a build and unit tests. You would still need to ensure that there are unit tests for any new functionality he adds, which you can do by looking at his checkins.
However, this is a human problem, so a technical solution can only go so far.
为什么不直接和他谈谈呢？ 他可能不会真的咬你。
Why not just talk to him? He probably won't actually bite you.
让他“照顾”构建，并成为构建经理。 这将减少他开发代码的时间（从而提高每个人的绩效），并告诉他为什么良好的构建如此必要。
强制执行测试用例 - 如果没有单元测试用例，则无法提交代码。 修改构建系统，以便如果测试用例无法正确编译和运行，或者不存在，则整个任务签入将被拒绝。
-亚当
Make him "babysit" the build, and become the build manager. This will give him less time to develop code (thus increasing everyone's performance) and teach him why a good build is so necessary.
Enforce test cases - code cannot be submitted without unit test cases. Modify the build system so that if the test cases don't compile and run correctly, or don't exist, then the entire task checkin is denied.
-Adam
发布每个开发人员测试代码覆盖率的统计数据，这将是在与他交谈之后。
Publish stats on test code coverage per developer, this would be after talking to him.
以下是来自海上棚屋的一些想法。
等等。用“马虎的开发人员”代替“醉酒的水手”。
Here are some ideas from a sea shanty.
etc. Replace "drunken sailor" with a "sloppy developer".
根据您使用的版本控制系统的类型，您可以设置签入策略，强制代码在允许签入之前通过某些要求。 如果您使用的是 Team Foundation Server 这样的系统，它使您能够指定签入的代码覆盖率和单元测试要求。
Depending on the type of version control system you are using you could set up check-in policies that force the code to pass certain requirements before being allowed to check-in. If you are using a sytem like Team Foundation Server it gives you the ability to specify code-coverage and unit testing requirements for check-ins.
您知道，这是避免孤立他（尽管我同意您需要与他交谈）并在内部实施测试优先流程的绝佳机会。 如果规则不明确并且期望众所周知，我发现您所描述的情况并不少见。 我发现测试优先的开发方案对我来说效果很好，并且提高了代码质量。
You know, this is a perfect opportunity to avoid singling him out (though I agree you need to talk with him) and implement a Test-first process in-house. If the rules aren't clear and the expectations are known to all, I've found that what you describe isn't all that uncommon. I find that doing the test-first development scheme works well for me and improves the code quality.
他们可能过度关注速度而不是质量。
这可能会诱使一些人急于解决问题以清除他们的列表并查看稍后错误报告中返回的内容。
要纠正这种平衡：
They may be overly focused on speed rather than quality.
This can tempt some people into rushing through issues to clear their list and see what comes back in bug reports later.
To rectify this balance:
对等编程是另一种可能性。 如果他和团队中另一位熟练的开发人员一起工作，并且满足质量标准并且了解流程，那么这有一些好处：
所有这些都要求公司和开发人员能够接受这个过程，但他们可能不会。
Peer programming is another possibility. If he is with another skilled developer on the team who dies meet quality standards and knows procedure then this has a few benifits:
All of this of course requires the company and developers to be receptive to this process which they may not be.
对于这个问题，人们似乎想出了很多富有想象力和狡猾的答案。 但事实是这不是游戏。 设计复杂的同伴压力系统来“点名羞辱”他并不能解决问题的根源，即。 他为什么不写测试？
我觉得你应该直接点。 我知道您说您已经与他交谈过，但是您是否尝试过找出他不编写测试的原因？ 显然，此时他知道他应该这样做，所以肯定有某种原因导致他没有按照要求去做。 是懒惰吗？ 拖延？ 程序员以他们的自负和强烈的观点而闻名——也许他出于某种原因坚信测试是浪费时间，或者他的代码总是完美的并且不需要测试。 如果他是一个不成熟的程序员，他可能无法完全理解他的行为的含义。 如果他“太成熟”，他可能就太固执己见了。 不管是什么原因，都要解决它。
如果确实是意见问题，你需要让他明白，他需要把自己的个人意见放在一边，只遵守规则。 明确表示，如果他不可信会遵守规则，那么他将被替换。 如果他还是不这样做，那就这么做吧。
最后一件事 - 记录您的所有讨论以及由于他的更改而出现的任何问题。 如果情况最糟，您可能会被迫证明自己的决定是合理的，在这种情况下，拥有书面证据肯定是无价的。
It seems that people have come up with a lot of imaginative and devious answers to this problem. But the fact is that this isn't a game. Devising elaborate peer pressure systems to "name and shame" him is not going to get to the root of the problem, ie. why is he not writing tests?
I think you should be direct. I know you say that you've talked to him, but have you tried to find out why he isn't writing tests? Clearly at this point he knows that he should be, so surely there must be some reason why he isn't doing what he's been told to do. Is it laziness? Procrastination? Programmers are famous for their egos and strong opinions - perhaps he's convinced for some reason that testing is a waste of time, or that his code is always perfect and doesn't need testing. If he's an immature programmer, he might not fully understand the implications of his actions. If he's "too mature" he might be too set in his ways. Whatever the reason, address it.
If it does come down to a matter of opinion, you need to make him understand that he needs to set his own personal opinion aside and just follow the rules. Make it clear that if he can't be trusted to follow the rules then he will be replaced. If he still doesn't, do just that.
One last thing - document all of your discussions along with any problems that occur as a result of his changes. If it comes to the worst you may be forced to justify your decisions, in which case, having documentary evidence will surely be invaluable.
将他放在他自己的开发分支上，只有当你知道他的东西经过彻底测试时才将其放入主干。 这可能是分布式源代码控制管理工具（如 GIT 或 Mercurial）的优势所在。 尽管 SVN 中增加了分支/合并支持，但您在管理它时可能不会遇到太多麻烦。
编辑
只有当你无法摆脱他或让他改变他的方式时才会这样做。 如果你根本无法阻止这种行为（通过更改或解雇），那么你能做的最好的事情就是缓冲团队其他成员的编码带来的不良影响。
Stick him on his own development branch, and only bring his stuff into the trunk when you know it's thoroughly tested. This might be a place where a distributed source control management tool like GIT or Mercurial would excel. Although with the increased branching/merging support in SVN, you might not have too much trouble managing it.
EDIT
This is only if you can't get rid of him or get him to change his ways. If you simply can't get this behaviour to stop (by changing or firing), then the best you can do is buffer the rest of the team from the bad effects of his coding.
如果你所处的位置可以影响政策，请做出一些改变。 在签入之前进行代码审查，并使测试成为开发周期的一部分。
If you are at a place where you can affect the policies, make some changes. Do code reviews before check ins and make testing part of the development cycle.
看起来很简单。 把他作为一个要求，如果他做不到，就更换他。 你为什么要留着他？
It seems pretty simple. Make it a requirement and if he can't do it, replace him. Why would you keep him?
我通常不提倡这样做，除非所有其他方法都失败了......
有时，公开显示的开发人员错误计数图表可以施加足够的同行压力以获得有利的结果。
I usually don't advocate this unless all else fails...
Sometimes, a publicly-displayed chart of bug-count-by-developer can apply enough peer pressure to get favorable results.
尝试一下胡萝卜，让它成为一个有趣的游戏。
例如 Hudson 的持续集成游戏插件
http://wiki.hudson-ci.org/显示/HUDSON/The+连续+集成+游戏+插件
Try the Carrot, make it a fun game.
E.g The Continuous Integration Game plugin for Hudson
http://wiki.hudson-ci.org/display/HUDSON/The+Continuous+Integration+Game+plugin
根据某些逻辑，例如每个功能、每个错误修复、每个开发团队等，将开发人员放在代码的分支上。 然后，不良签入将被隔离到这些分支机构。 当需要进行构建时，合并到测试分支，发现问题，解决问题，然后将版本合并回主分支。
或者删除该开发人员的提交权限，让他们将代码发送给年轻的开发人员进行审查和测试，然后才能提交。 这可能会促使程序发生变化。
Put your developers on branches of your code, based on some logic like, per feature, per bug fix, per dev team, whatever. Then bad check-ins are isolated to those branches. When it comes time to do a build, merge to a testing branch, find problems, resolve, and then merge your release back to a main branch.
Or remove commit rights for that developer and have them send their code to a younger developer for review and testing before it can be committed. That might motivate a change in procedure.
您可以将代码中发现的错误与负责该软件的程序员的姓名放在一起。
如果他是一个通情达理的人，请与他讨论该报告。
如果他关心自己的“声誉”，请定期发布该报告并将其提供给所有同事。
如果他只听“权威”的话，就报告并将问题上报给他的经理。
不管怎样，我经常看到，当人们意识到自己在外面看起来有多糟糕时，他们会改变自己的行为。
嘿，这让我想起了我在 xkcd 上读到的东西 :)
You could put together a report with errors found in the code with the name of the programmer that was responsible for that piece of software.
If he's a reasonable person, discuss the report with him.
If he cares for his "reputation" publish the report regularly and make it available to all his peers.
If he only listens to the "authority", do the report and escalate the issue to his manager.
Anyway, I've seen often that when people are made aware of how bad they seem from outside, they change their behaviour.
Hey this reminds me of something I read on xkcd :)
您是指在签入之前编写自动单元测试还是手动单元测试？
如果您的商店不编写自动化测试，那么他签入不起作用的代码是鲁莽的。 对球队有影响吗？ 你们有正式的质量保证部门吗？
如果您都在创建自动化单元测试，那么我建议您的代码审查过程的一部分也包括单元测试。 在您的审查过程中，很明显，根据您的标准，该代码是不可接受的。
你的问题相当广泛，但我希望我提供了一些方向。
我同意菲尔的观点，第一步是与他单独交谈并解释质量的重要性。 质量差往往与团队、部门和公司的文化有关。
Are you referring to writing automated unit test or manually unit testing prior to check-in?
If your shop does not write automated tests then his checking in of code that does not work is reckless. Is it impacting the team? Do you have a formalized QA department?
If you are all creating automated unit tests then I would suggest that part of your code review process include the unit tests as well. It will become obvious that the code is not acceptable per your standards during your review.
Your question is rather broad but I hope I provided some direction.
I would agree with Phil that the first step is to individually talk to him and explain the importance of quality. Poor quality can often be linked to the culture of the team, department and company.
在某件事被视为“完成”之前，将已执行的测试用例作为可交付成果之一。
如果你没有执行测试用例，那么工作就没有完成，如果在你有记录的测试用例执行之前就已经过了最后期限，那么他就没有按时交付，后果就和他已经交付一样未完成开发。
如果您公司的文化不允许这样做，并且它更看重速度而不是准确性，那么这可能就是问题的根源，而开发人员只是对现有的激励措施做出反应 - 他因做了很多事情而获得奖励半途而废的事情而不是正确的事情更少。
Make executed test cases one of the deliverables before something is considered "done."
If you don't have executed test cases, then the work is not complete, and if the deadline passes before you have the documented test case execution, then he has not delivered on time, and the consequences would be the same as if he had not completed the development.
If your company's culture would not allow for this, and it values speed over accuracy, then that's probably the root of the problem, and the developer is simply responding to the incentives that are in place -- he is being rewarded for doing a lot of things half-assed rather than fewer things correctly.
让人们清洁厕所。 曾在军队工作。 如果你和一群经常吃印度菜的人一起工作，他们很快就会排队。
但这只是我...
Make the person clean latrines. Worked in the Army. And if you work in a group with individuals who eat a lot of Indian food, it wont take long for them to fall in line.
But that's just me...
每当开发人员检查无法编译的内容时，就将一些钱放入罐子中。 那么在办理入住之前您会三思而后行。
Every time a developer checks something in that does not compile, put some money in a jar. You'll think twice before checking in then.
不幸的是，如果你已经和他谈过很多次并向他发出书面警告，我会说现在是时候将他从团队中除名了。
Unfortunately if you have already spoken to him many times and given him written warnings I would say it is about time to eliminate him from the team.
您可能会在这里找到一些有用的答案：如何让初级程序员编写测试？
You might find some helpful answers here: How to make junior programmers write tests?
我很想建议详细说明您尝试过的内容以及获得的结果，因为这可能已经发生了一些变化，但这是我最初的建议：
是否有任何测试或综合测试？ 有些人可能会盲目编码并进行零测试，但这种情况相当罕见，IME。 通常会做一些测试，但不足以覆盖大部分需要综合测试的情况。
团体动态可能会有所帮助。 我假设他是团队的一员，团队的观点可能会有所帮助。 在某种程度上，这是试图获得同侪压力，这通常是一件坏事，但有时它可以用在好的方面。
警告的拼写是否清楚？ 在某种程度上，这看起来很幼稚，但你所认为的测试可能与他的不同。 您是否想要 nUnit 测试、Excel 电子表格、计算机日志或其他东西作为测试存在和使用的证据？ 根据您的描述，没有任何内容可以证实他确实理解您的意思，将使用测试并提供这样做的证据。
入住政策问题。 有些地方，比如我现在的工作场所，鼓励经常提交，这可能意味着人们确实会在没有测试的情况下提交代码。 您所在的地方是否有已知、接受且得到广泛遵守的政策？ 这是另一个方面。
I'd be tempted to suggest elaborating a bit on what you've tried and what results you got as this may have changed a bit but here are my initial suggestions:
Is it any tests or comprehensive tests? Some may code blindly and do zero tests, but this is rather rare, IME. Usually there are some tests done but not enough to cover most of the cases that would be comprehensive testing.
Group dynamics may help. I'd assume he is part of a team and that the team's view may be of some help here. In a way this is trying to get peer pressure which is usually a bad thing but sometimes it can be used in good ways.
How well spelled out were the warnings? In a way this can seem childish but there is a chance that what you think of as testing may not be the same as his. Do you want nUnit tests, an excel spreadsheet, logs from his computer, or something else as proof of the existence and use of tests? From what you've described there isn't anything to confirm that he did understand what you meant, was going to use tests and provide evidence of doing so.
Check-in policy question. Some places, such as my current workplace, encourage committing often which can mean that one does commit code without tests. Is there a known, accepted and well-followed policy where you are? That's another aspect here.