What is the best way to introduce TDD, DI, CI to a dev team

Question

There are many new concepts to learn for a typical asp.net webform developer who is happy with their event driven, drag and drop world where the code behind is abstraction enough.

What is the best way to introduce the concept of mvc, unit testing, loose coupling, dependency injection and continuous integration whilst still maintaining efficiency in the day to day project work.

I believe it would be foolish to try and introduce all the concepts at once. The learning curve is quite steep and the chances are you will end up confusing them and they will not grok the concepts. This could lead to a lack of confidence & apathy leading to the whole learning process failing resulting in a team of confused & demotivated developers.

I was thinking to find some time for a side project, maybe a collaborative rewrite of an existing system that is not too involved. However to be a worthwhile exercise then serious time needs to be invested and it cannot be a done using half a day per week.

How to break the concepts down, what should be introduced first? What are your experiences?

Answer 1

Start with continuous integration. People will get benefit from that alone without having to change their behavior.

Ask people to write JUnit tests for new code, refactoring, and whenever a defect comes in. Write the test, duplicate the error, fix it, prove the fix. You can build up test cases without having to do a "big bang".

You have to get project managers on board with unit testing. Tell them they're trading off writing and maintaining new test code for fewer defects later on.

CI is another matter. Start small, and train people. I think it facilitates testing, so perhaps that'll help.

MVC and loose coupling are design issues. Do them with one project and give people a chance to get used to it. Training is key. Got any budget for books or classes?

Find a mentor. Maybe a consultant who's more than a Power Point presenter can guide you over the shoals.

Answer 2

Small advice: get a copy of Fearless Change. I never actually got to reading it, but an interview with an author was very promising.

Answer 3

Just do it.

Seriously.

If YOU start writing tests first, and you produce higher quality code, then you have a living example they can learn from.

If YOU are doing continuous integration, and you have a living, working example, then you can insist others cooperate by not breaking the build. They'll learn how the do integration from your living, working example.

If YOU are using a dependency injection centered design, if you are using loose coupling, then you have working examples of best practices. Start a blog. Record your design process in daily blog postings. They'll learn from this.

Yes, they will produce bad code at first. Once they start learning, they will start fixing. Change is disruptive. New skills take time to master. Plan for the rework.

Also, don't pontificate to them about how they should be working. Just work better yourself and be the best example of how well things can be done.

Answer 4

Whenever a bug is fixed, have the developers write a test to ensure the bug doesn't happen again. Developers are usually motivated to do this and will be happy once they see the results. Make sure they have written a unit test, not an integration test. Everything else will stem from there.

Answer 5

Find a willing guinea pig who you can get to try out the concepts on a side/small project. Guide them on the basics, how to go about stuff, but try to let them find their way. This lets them boost their own confidence and gain an achievement out of it, leading to them sharing their enthusiasm with the rest of the team.

Worked for me, I was that guinea pig and now I actively champion TDD within the team and never look back

Answer 6

I think it depends on your team and the experience of the team members. If anyone has experiences in one of the DI he/she should prepare a small workshop to show what DI is useful for. The workshop should contain hands on sessions. Additionally some links, documents... should be used as preperation material to get into the topic before the workshop.

And of course: Buy books and hand them over to your team.

Answer 7

Ask people to watch this: http://www.asp.net/learn/mvc-videos/#MVCStorefrontStarterKit

I made this series for this scenario. There's a lot of footage here but I cover as much as I can to inform people.

Then have the debate :)

Answer 8

As you say, it would be foolish to try and do it all at once.

MVC is sort of separate from the others since it is a framework choice and thus cannot be introduced gradually throughout a project. I'm going to focus on the other methods.

For introducing those, the natural order would probably be: CI, unit testing, design principles (loose coupling etc), DI. Start with the simplest thing, and then show your team how they could get even more done by adding just one more little thing to their toolkit.

Continuous integration is a good first step. It is simple to introduce, costs almost nothing, does not require your developers to majorly change how they think, but produces benefits from day 1.

Once people get used to those benefits, introduce the next step. What if each build could tell you not only that everything compiles, but also that it works correctly? Thus, unit tests (and other types of automated tests). Start small and simple, test the components that are easy to test (but still meaningful to test) and work onwards from there.

As your team starts to introduce tests, they will notice that some things make testing easier. This is a good time to start learning about design principles such as loose coupling. It's important, though, to not just represent these principles as good for making the code easier to test. "Easy to test" is not a goal in itself, more a symptom or a sign of general good design.

And as you test more and more, your team will notice that even with good design, some things are difficult to test. This is when you tell them about dependency injection, mocking etc.

Answer 9

TDD should be a good thing to start from. It's perhaps the most fundamental technique to learn as it completely changes the way you think about writing code. Once you learn that, then many of the other techniques (such as DI and CI) will begin to make more sense or will be more useful.

I learned TDD by just starting to use it in a project. There was a small utility application that I had to write at work (a couple of weeks of work) so I chose to write it 100% using TDD. Previously I had read many articles how to do TDD, after which a couple of weeks of practice using it was enough to learn the basics. After that I still needed concentrate for example on improving the quality of the tests that I write, but then I was already using TDD in all my projects and had more opportunities to continue learning.

I recommend choosing a low-risk greenfield project and using it to experiment new techniques together with a couple of team members. If there are no such low-risk projects (or ones without tight deadlines) at your workplace, then use some toy projects. Pair programming will surely help, because then you can support each other continuously during learning and beyond. If you already know some TDD, you can stay more in the background and instruct the others how to the work (i.e. when pair programming, the less skillful person is the one doing most of the typing).

It would be best to get support from the management, so that you can allocate work time for improving your skills (maybe one day per week - I think at Google they have it like that with their "20% time"). Of course the best developers are already allocating their free time for that, but you would want to improve the whole team and not just one or two individuals - otherwise those one or two top developers will sooner or later move to another company where there are more skillful peers to learn from (and possibly also better pay).

Answer 10

The company that I worked for didn't have any set testing approaches when I arrived. The approach that I then took was to suggest the idea to the development director and ask for someone to guide them through the process of writing unit tests.

Once I showed the developer best practises and the ideas of mocks I let them loose on their project. It wasn't TDD but was a start. The development director was impressed that he allowed him to do this with all future projects. I then tackled the idea of Continuous Integration with everyone and since there were already unit tests we were able to see how changes were affecting the build and breaking tests.

From there I tackled TDD. This is proving to be the most difficult idea since some developers can't understand the concept of testing first but have won people over by suggesting Behaviour Driven Development. The removal of the word test has got people more interested.

When you have got the basics sorted then I would only have a look at agile concepts like pair programming.