I am the only person on my team that use TDD. How do I make them to use it?
I am annoyed that when I pull, someone's code will break my tests and I am the one who has to fix them.
Will using github, fork and pull request solve this problem, so that they need to pass the test before the pull is accepted?
I am not the project manager and I can't seems to convince her to use it.
The way I see it, the only way to convince for anything about tests is to demonstrate that they are useful - ie that test failures help to find and fix bugs.
The way you describe the problem though, looks like this is not the case here. Look...
...when I pull, someone's code will break my tests and I am the one who has to fix them.
If I understand correctly, you mean you have to modify tests. Well, that does not sound like test failures help to find and fix bugs does it? If tests don't help in finding bugs, it's pretty weak position to start convincing your colleagues - what could they expect to gain? tedious fixes in fragile test code?
This may sound like a dead end, but it really isn't. Your final goal (convince for TDD) still makes pretty good sense, don't drop it. Just re-focus your efforts on removing the obstacle you discovered.
Test failures that bother you now are essentially "false alerts" - meaning these are bugs in tests not in the code. Use these as an opportunity to improve tests, to learn how to make good reliable test design. Work on tests to make "false alerts" less frequent and to make it easier to discover real bugs in tested code.
As you discover real bugs, let your colleagues know and help them fix - and don't forget to point that these bugs are found by your tests. That will make a really solid ground to convince your colleagues.
It is worth mentioning that test design skills you develop at "preliminary" stage will most probably be needed again, if (when:) you finally convince your teammates to use TDD. Think of it...
...What would happen when test driven development is introduced to your inexperienced colleagues?
First thing to expect is that guys will start writing crappy tests and (horror!) even breaking good ones while learning. To help them find a way to do it right you'll need quite a solid understanding of good test design.
All the errors you find and fix in your tests now, will be repeated again and again by all your teammates when they begin learning. If (when!) that happens, you would better be prepared to quickly and clearly explain how to improve if you want them to remain positive about TDD.
When I wanted to encourage the use of Test Driven Development I ran a Cyber-Dojo. With this sort of exercise, the emphasis is not on the code itself, but on the process of writing the code.
We spent an afternoon, in pairs, repeating the same kata, but under different conditions. We started with all groups doing one exercise at the same time. This provided a baseline.
We then discussed some of the basic principles of TDD, had everyone change partners and repeat the same kata. We repeated the same kata to de-emphasise the generation of code and instead concentrate people on the process of naming test cases and the Red/Green cycle.
Then we repeated the kata again, but roughly every 10 minutes one person in each group would move to another group, simulating the rather fluid team environments we often find ourselves in these days.
In the final iteration, we had both partners change every 10 minutes or so into different groups. This helped to demonstrate that with TDD, even the handover from one team to a completely different one needn't necessarily be too painful, since the project should only every be one Red/Green cycle from working.
The interesting thing was, there were few people who had done any TDD before the session, but what TDD knowledge there was rapidly spread until by the final iteration through the kata, most people were thinking in a TDD way or could at least appreciate why it might be beneficial.
People generally said that the afternoon was both fun and informative and we are now looking at other ways to use Cyber-Dojo at my workplace.
Cyber-Dojo, written by Jon Jagger, works incredibly well for this sort of exercise. It is a web based integrated environment for doing deliberate practice of TDD and learning about team dynamics. It has lots of kata's selected specifically to help people concentrate on the process of TDD and not the problem. It also supports a range of languages, from Python and Ruby to Java and C++.
The best thing is, after doing a kata you can then go back and look at the red/green progression (or maybe not *8') of each of the groups participating. It's traffic lights are a great way to visualise how the TDD process works.
If you want your own CyberDojo server, the whole project can be found at github and there is even a Turnkey Linux appliance virtual machine linked from there, which means that assuming you already have VMware player or VirtualBox installed, you can be up and running within a few minutes of downloading the appliance!
If they resists TDD, it is ok. Many people (including myself) are having problems with writing unit tests first.
However, you should raise a question about having no unit tests at all, and the issue of unit tests breaking. Unit tests are a safety net that prevents lots of possible bugs, and allows code refactoring. Explain about higher code quality, and cleaner code.
I think the best would be to find a video that explains advantages of using TDD, and show it on a meeting.
If she refuses to listen, then you can try to go to someone above her, but that might not be very smart if your boss is so stubborn.
It's really hard to convince people to change their habits, but here are some things you can try:
If none of this works at all, you might want to consider working somewhere else. There are plenty of other companies that where your life would be considerably easier.
There are 2 slightly different issues here: getting people to do TDD and people breaking your tests.
I'm not sure about the first issue, personally I find it an artificial way of working and not suited to all types of development. I'm all for having a good suite of unit tests, but I usually find it more efficient to write the code first and then the tests, since while writing the code my ideas are always changing, and it's a waste of time writing tests too early (IMO).
On the second issue, set up the project so that unit tests are run on check-in, so that other developers don't have any choice but to know they've broken a test.
As said in a lot of other "how should I convince X to use Y method/technology", my answer is always the same: by example.
Use it and have better (mesurable) results. Then make sure the others notice.
On an existing project, you don't. It's the same as if you'd be making changes to the way curly brackets are placed in legacy code because you dislike the indentation style.
Lots of good advice. And now, a bit more...
You must win hearts and minds (WHAM) one Luddite at a time. Forget about forcing it down their throats. Lots of object lessons over an indefinite (sorry about that) period of time. Eventually you will hit a critical mass, convince the "right" person(s).
Your constant and consistent enthusiasm & avocation for TDD is very important in a WHAM campaign.
You must turn the test-breaking and code changes into teachable moments, the lessons which matter for your co-coders. Make it personal. I.E. Do they care about a reputation for delivering above average clean code? Do they care about management ragging on them about code that is now late because integration testers gave them a reality check? Does Jack have a desire to modify some difficult code but is afraid of side effects?
Gather good examples of test-breaking as trapping coder-induced bugs. The coders will see changing tests as unnecessary work to irrelevant code; they must understand that the tests just covered their arses.
Find some code with global implications (some simple utility method), build some tests, then demonstrate that tests permit change w/out fear of earthquakes throughout the application. And I do mean to emphasize the emotional issue too!
Gather some simple time-to-clean-code examples (i.e. passed into production) and demonstrate that despite the extra effort for test coding, we got her done faster & with higher quality.
Warning: TDD is not a cure for and cannot overcome bad OO design and coding (but it definitely can expose it). Do not let the Luddites blame the testing code effort for their incompetence.
I'd try try again to convince the manager. From what you've written, I don't think you could convince your teammates to do TDD behind her back.
You have to speak her language. Manager tend not to be impressed with technology, but they understand the business language:
tests will save time during development, because instead of manual testing (trying to reproduce bug locally, playing with the rails console...) you will be running tests automatically
test will save a lot of time during application maintenance, when you can easily detect bugs whenever you change something. Explain that tests require higher initial investment, but they'll pay for themselves in the long run (maintenance of good tests is usually quick and easy)
and what will you do with the extra time? create moar stuff and make them moar money :)
As for programmers, try this argument (it worked for me, way back): "You're testing code anyway, with or without TDD. Only you do it manually instead of automating it. Smart developers automate as many things as they can."
On real projects with deadlines people want to focus on getting the work done with what they know. That's just human nature. And if you never learned TDD, you would be the same as her in this situation. I guarnatee it.
Why doesn't the garbage collection crowd love, learn, and live RAII? How could you champion automatic memory management but hold on to the old fashioned management for general resources like files, connections, etc? Because RAII is a technology they don't know, understand, and don't have time to use when they have a deadline that needs work done.
I bet you don't use RAII and aren't willing to learn and understand it for your current project. Same as your coworker who is not willing to learn and understand TDD.
