On our quest to be a TDD driven team, one of my colleagues had a great suggestion. That is to watch a video together once a week while we also try to code TDD. I totally agreed as I was thinking the same in that we should all be watching about basics first to get a foundation in addition to just "diving in" and some of our guys have not had the time to watch videos what I really feel is important for us to watch. The rest of the team thought that was a great idea as well. Our boss also started us doing some Mob Programming. It's pretty neat. Our team doesn't don't do it all day every day to the extreme whereas some places do as it's not our methodology. We are a SCRUM based agile development shop, but we are stealing that idea and applying it for an hour taking 2-3 times a week, bringing in the entire team or immediate devs on your project come together in a conference room and work on real production code together via these Mob sessions. In our mob sessions, one person drives. We rotate the driver every session so everyone is forced to be a driver. Then we all start to code real code together. Think about is as like one huge XP session where production code is getting done and everyone is learning at the same time. If you can't make a session it's alright, it's a come as you want basis but usually we have several devs show up to at least a couple sessions a week so we end up being productive in it. As a teammate, I'm also trying to contribute by helping myself and everyone up to speed and doing TDD as much and as fast as possible. To do this though, we know that it will take time to get it right as we are all new to this. We also need to keep in mind that this is not just a technique, this is a total change in mindset and attitude when you do TDD and that there are principals that when followed, work. Anyone starting a team out doing TDD might question some things about it or how you do it. But we know there will be a period of learning why and how and that yes, there will a cost in that there will be slower development going on but that there will be a threshold met when we get used to it and able to fly with it and it will be a no brainer. This is when the business starts to see fast and quality end results out of their development team to a degree that they have never seen before. But this won't happen unless you follow the 3 principals in order and refactor your tests to be DRY as stated in the diagram during that process. Principals of TDD have been proven and successful for a long time now. This is not some theory or "achedemic" set of rules being forced on you or a "we are doing it because everyone says we have to do it this way" as some people might view it. These are not principals you say "oh we don't have to do it quite that way, we can write tests after and come back and write the test". These are principals that depend on each other and depend on you doing it in the right order. If you don't adhere to failing test first, etc. then that's not TDD and that will not provide you the benefits you are seeking. If you are not writing failing tests first, then please do not call it TDD. This is not a discipline you just take for granted or twist and turn into your own way of doing it. There are 3 principals. If you force yourself to figure it out, understand it, practice it and follow it as does all other TDD shops who have been successful at it, you will reap its benefits. If you do not, you will eventually end up with a mess plain and simple and sadly will never know TDD as it was meant to be applied and never reap its benefits. Having unit tests is great. Driving new code with TDD is awesome. Just stick to the principals when you do it is all I'm saying. As a side note, I've been on so many teams in the past who get lazy and write tests AFTER for any new code, and it just ends up in a huge ;pile of shiza, and lot of inconsistent useless Unit Tests that test more than one thing, test things that do not relate to the use case, as well as high confusion over WHAT should be tested after the fact. Or I've been on teams that do not see the value in unit tests at all and will do anything to deter you from spending time doing them. And let me say sure, obviously you can't apply TDD to all of your code as you will have legacy code as well. But if you are test driven, eventually all new code will be created with this technique and mindset and, you will no longer have to be wasting your time wondering if you are writing the right tests or if your tests are too big, etc. Because when you can do TDD when writing tests, as you code, you are forced to THINK about what you are coding and how you are meeting the business requirements and again, failing tests first coding classes and methods that do not exist yet force you to think about what you really do need (simplicity) for that business requirement. That hardest part is to change people's mentality but more importantly devs don't get that your tests should be so freakin small you think it's ridiculous. But that's the point. A lot of devs typically in early stages will say do we really need that many tests and to spend time writing so many? Do we really need to test something that small? the answer should always be without question YES if you are buying into the technique and mindset of TDD. Otherwise you loose its benefits. You should have many tests...small as hell, testing one thing, and even if you think it's too simple to test, that's not the mentality you should have in TDD. You will have several tests for "a" method in a class. There is no "too simple to test" idea or concern here. A "unit" is testing ONE thing. And that ONE thing should be very very very very small. You have to get that mentality in your head and accept it. For me it makes total sense and I don't have that conflicting urge not to do that. Personally I want a lot of small tests, ti just makes sense and I know it's gonna help find bugs very quickly and that you can trust your tests because they are so small there is no doubt about what to call your test, or that you are introducing bugs into your tests. You will write tests and over time get good at it and the automation of all this will save hundreds of thousands of hours each year for the dev team and the business in the long run. So going back to our video sessions. The first video I suggested which we watched this week was Unit Testing Best Practices with Roy Osherove. And the reason I suggested this one as opposed to jumping right into TDD videos was because it's just as important for you as a developer to know traits of what makes good unit tests (TDD or not). This video by Roy is not about TDD although he does relate to some TDD in it. But it's more about how to write good tests. I felt that it would be a good suggestion that we take that step backwards and then into TDD videos after and I think the team liked it and it was a beneficial video to start with as far as I could tell. I also suggested the next video to be the following from Uncle Bob to be Clean Code → Episode 6, TDD - Part 1, as I bought it tonight and thought it was very good. He explains the benefits of TDD better than any video I have watched yet and also drives home how important it is to STICK to the 3 principals of TDD and why you should not deviate or mess with the formula. It addresses a lot of concerns people who are not experienced with TDD have, common responses you get (oh it'll take too much time to code all these tests, yada yada) that try to push TDD out and keep it from penetrating your development team as a way to develop code. We're having fun as a team, but more importantly learning together and a unified goal to create better code, have test driven code that will save us a ton of time later on and our boss is totally on board and motivating that drive. That's one of the problems in our trade...finding a good team and a good manager. That doesn't always just come easy as a lot of my friends have experienced the same. So point is you have to have a manager who is invested and passionate on improving the business and the team. I think this is the kind of team every developer should want to work with. Who wouldn't right? If you are not working for this kind of team then maybe you want to seek one out. It may take a long time to find and a dime a dozen but they are out there from what I've learned. It's fun, we get stuff done, we know things will improve over time with TDD and cleaner code, and we know as this progresses, if we stick to our guns, we'll get to go home to see our kids and wife without worrying about shit at work like fires, meeting deadlines..stuff like that which makes your life hell on some dev teams I've been on in the past. So taking an hour out as a team to watch videos from some great people (Uncle Bob, Roy Osherove, etc.) it's great parallel step as a team toward TDD development as we also do Mob programming together. Also we've decided to try to attend a Dev events outside of work together as a team (or at times we may even take a half day of work to go to these). The first session we attended was one by Uncle Bob that you can find and watch here: While we are not 100% an XP based agile shop (again we're primarily SCRUM) we still also do pair programming as well quite often in fact. We will go to each other's desks and code together (one codes, one observes) and the productivity level increase is just astonishing and is the only way to go on any development team as far as I'm concerned. So as we start to do more TDD together, I will post Part 3 of this series which shouldn't be too much longer...we're gaining ground more and more on this adventure.