Clever Geek Handbook

Developers are unhappy with TDD. Is TDD really a problem, or is it a lack of skills as a beginner?

(This is not a question for exploring the merits of TDD. There are other places for such discussions. Thanks in advance.)

I have experienced too many developers who are new to the technique who also report dissatisfaction with test driven and NUnit driven development.

I hear negative comments like:

  • " I don't like NUnit. I tried it a year ago, but I forgot how to use it . Just use this Windows Form application. I just wrote ad-hoc as a test harness instead. Test code is code to eject anyway , what's the difference? Anyway, my way has worked well enough in the past. "

  • I have reservations about TDD . In our last project (which was my first and only project with TDD , by the way, / strong>), we don't even know what design is.

  • "More BAD code comments? Are you crazy? I really have a job if you don't mind." (From the old school, more comments are better comments, and you'll never have too many comments.)

When a newbie complains that TDD allegedly "didn't work" with their satisfaction on their first project using TDD, is it really TDD that failed them , or is it the developer himself whose skills are not enough to get good results ?

And how can I report this if they don't hate me for it?

The crux of the matter is, what can we tell diplomatic developers to encourage them to more honestly assess their own emerging and gaps with new development technologies without jeopardizing our important working relationship?

Typically, many developers are clearly not yet equipped with the working prowess of many of the important elements of TDD to debug very well in the very first project.

For example, the typical complaints in the developer community that I spoke to:

  • Never even tried to look at or remember a list of code smells.

  • Never even tried to study the refactoring catalog and did not practice any of them in either real projects or toy projects for teaching. For some people there might be a lot more OOP to learn, just to be able to refactor very well. Refactoring is much less common than simply "rename method" and "rename variable", which appear as items in the Visual Studio 2005 refactoring menu.

  • Never even tried to study or participate in real projects implemented using emergent design (through refactoring), versus doing the whole project using the design in advance, versus a whole project that only writes unit tests after writing the code, and knowing the differences and tradeoffs and their applicability between any of them.

They all seem to have used NUnit once , so whatever they do with it is TDD, as golly seems to be thinking. Having NUnit or unit tests just doesn't imply TDD, but they don't understand enough that they don't even know it.

They are smart people. Developers are smart people because this is the bar to enter all classes. Otherwise, you cannot be in the profession for too long. Of course, they could understand this if they tried to study these materials for some time.

How can people honestly tell themselves that a methodology is weak when their sum of experience and knowledge is something that is obviously too weak to even be able to evaluate the methodology or its results?

But they ... This is self-protective behavior, I believe. Or is it laziness. If you can't even name three refactorings from Fowler's book catalog Refactoring, or if you can't name a few code smells, you're an early beginner at refactoring and probably also the whole TDD methodology and your so-called 1 or 2 project experiences, obviously not enough.

What can I tell people or what materials can I bring people to their attention to get them to do whatever it takes to learn more about the skills that are critically dependent on the success of TDD, for example:

  • unit testing,
  • refactoring,
  • design patterns,
  • OO design and analysis?

There are entire books on each of these topics, some very good ones. Maybe there are easier ways to swallow? I can teach people by examples, but my own time to give them is limited, and besides, I am not yet a black belt in all of these methods.

Moreover, they go together. They don't work very well without each other. Unit testing and refactoring go together like peanut butter and jelly. If you can't test the grep unit, then you probably won't get very good results with your refactoring! (Ask me why, if you don't already know, I'm happy to explain this to new people.)

It is also vital that whatever I do or say does not backfire:

I shouldn't alienate my colleagues from TDD concepts ; and moreover, I should not alienate my colleagues from me. I will have to work with them every week for many more years.

It is especially difficult not to upset other longtime senior developers who have already proven themselves to be professionals in other aspects of programming. They are justifiably proud of their past accomplishments, but their egos or their self-esteem of mastering all things in programming can be almost overwhelming to deal with without hurting their feelings. Some senior developers don't have to deal with the fact that they don't know new techniques that they should learn from someone else. Senior developers can be more familiar and comfortable with being experts in the room when it comes to programming, and sometimes they require to be treated as such even when it was completely unrealistic when it comes to TDD and related methods and technologies.

I'm happy to report that one way to get good at handling one of our persistent "resisters" when writing structured automated unit tests is to use pair programming with them one-on-one. I think that pair programming gives listeners real life examples and experiences, as well as direct tutelage of a more experienced and knowledgeable person.

But pair programming isn't enough. There are many other refactorings, code smells, OOP and OOD concepts and concepts that they need to learn, and I cannot teach them all in one project without even closing.

-4


source to share


12 replies


It is simply impossible to make your ideas relate to other people and accept them. You can use your own methods and others might want to know when they see good results. Do you just expect things like TDD, pair programming, etc. to bring magical benefits?

You also don't specify your role. (or at least I didn't find it)

You can try another way:

Offer a lunch workshop about TDDor nunit. Show the benefits you see. Provide REAL examples and real benefits for the developer / company. Without them, you won't have a receptive audience.

At least you have people who have written their own test harnesses - that's good. I would compliment this and ask for more information on this.



Ask the developers what they see in this problem and what testing they want or how the company can improve. You must stop imposing your ideas and let them come from them.

EDIT - from experience

Several years ago I had a similar experience. I read many books about the process and The Right Way to Develop Software (tm) and went on to tell everyone I saw about the right way to do things ... Nobody wanted to hear it. I realized that taking the risk of being marginalized didn't really get anything useful. So I just shut up and implemented some good practices in the group I just led. After about 4 months, people started asking us how we got the results we were delivering.

Instead of looking for others, people came to find us. (this was not my plan, but in retrospect it makes sense. People want results, not hot air)

+17


source


To redirect your question to one line:

And how can I communicate that without them hating me for saying it?


By being such a good developer, you earn their respect and then they will listen. There really are no short cuts here. My advice would be to become a better developer and a better evangelist. If you learn from the people you are trying to teach, then they can start learning from you.

And with all due respect, your attitude towards TDD comes across as pretty reverent. It won't help either. Combine that with the big culture change that TDD includes, and your chances of successful evangelism begin to dwindle.

+10


source


I think the biggest problem with TDD is people focus on these tests.

Testing is somewhat irrelevant. Submitting all your tests only proves that you passed all of your tests. Plus, you can pass all your tests, get full coverage, and still have a bad, unusable app that no one wants.

The gap between passing 100% of your tests and having a great product is the part of the profession known as the craft.

Also, TDD is another way to specify design. This is an important bit of TDD, as a result of which the design is blocked to some extent.

+9


source


It may not be that TDD is an issue, but do you think this is really the case for the environment you are working in and the type of project you are working on? You haven't mentioned anything about what problems you have (or even the methods and techniques you are currently using), and why you decided to use TDD to solve those problems. Are you sure that the resistance you see is not due to resistance to change, but because you are trying to solve a problem that does not exist?

TDD is not suitable in all environments. I'm sure when I work because we are working too fast, with specs that are usually written around to start and refine / change / rewrite on every iteration, so we don't have a defined behavior to test most of the time. In addition, we have developed methods that mean that the code does not need to be tested in many cases, because this method is a one-line method, which guarantees the stability of static type checking.

There are many comments in your post that mark you as someone who may be relatively inexperienced and who has hooked on a methodology that you think is a silver bullet that can solve all problems and that your colleagues should learn if they must keep up with you. Unfortunately, there is no silver bullet in software development, and if they are senior developers with a lot of experience and they don't believe TDD is appropriate, then it might just be worth listening to them.

You should also be aware that TDD is not a prerequisite for refactoring, as people who love the red green refactor mantra want to think it is. If you are refactoring a small area and know that it is affecting and can be easily tested manually, you can manually test that area during and after refactoring.

+7


source


Just to play devil's advocate, why are you so sure TDD is really effective? Personal experience? Empirical research?

Here are two studies that reported positive TDD results:

And two unconvincing ones:

I'm not sure if it's a good idea to present the methodology as if it were perfect. This is one approach that can be effective. As far as we know, there are even more effective approaches. Perhaps invite all developers to develop a mixed methodology that works for your organization.

+4


source


  • Nobody likes to be told that they are less than specialists in their profession. The older the person is, the more resilient they will be to accept the new methodology that makes them feel like a newbie.

  • The best success I have had with testing progress has been generating graphical test coverage reports and posting them to the team (or to the internal team's webpage connected to the continuous integration reports). Yes, test coverage is not a complete measure of quality, but it is a fairly simple way to show who is writing tests and who is not.

  • Let there be peer competition to see who can maintain the highest percentage of their code coverage. People love competition. As they lag behind, or if they write code with untested "code pockets", they might think about refactoring to make their tests reflect code coverage. If they don't like being "trained," then let them discover refactoring methods themselves. This way, they can continue to feel smart.

  • Or there are brown bag dinners in which people can showcase some clever refactorings they've done to achieve more testability. People love to show off! More than they like, they show their ignorance.

  • This is far from TDD, but at least it is some progress towards improving QC. Once they are more comfortable with the tools and a few easy ways to refactor, you can introduce a few more advanced things gradually: pair programming ... code reviews ... detecting code smells ... tracking test requirements. Then you can bypass TDD.

As Stephen Lowe said in this thread, Rome was not built overnight.

+4


source


Your real question is, "How do I convince my colleagues to try something new?"

This is a really good question, and a shame it is really difficult. I had a couple of conversations on this with Alistair Cockburn and I posted the slides but didn't write the text, but I can give a short version here.

Are you familiar with Adoption Lifecyle Technology or Chasm Crossing ? They relate to segments of the population and their motivation to change. A key idea that pertains to your situation is that only people on the left side of the chasm - innovators and early adopters - are interested in change to try and improve the situation. People on the right side of the chasm - most people - are more resilient to change, and when they change, it is not for the same reason as people on the left. As a result, the two groups tend to talk about each other.

You are the left side of the abyss. Your colleges are on the right hand side. If you keep giving them your reasons to change, you will not persuade them.

That will persuade them to try something new if it makes a solid promise of getting rid of some current pain they are feeling.

Talk about how TDD is best and what you should be doing and you are talking past them.

Talk about how TDD can fix some current pain, you will have their attention.

And the killer part? If there is no ongoing pain, you are unlikely to make them change, period.

This is why the parameters "change your organization or change your organization".

Good luck!

+3


source


rome was not built in a day + other cliches for patience

keep mating and set a good example and others will see the light and follow.

you can lead a horse to water, but you cannot make him drink. And if you push him to the water, he will either drown or run away .; -)

+1


source


Most likely the issue is that the performance degradation when using TDD style and creating the culture that TDD requires is where I think things go wrong.

Could these senior developers significantly reduce performance and that would be acceptable to everyone? If you figured that everything would be okay with rethinking code development then you might have something, but remember that most developers have their own personal optimizations for writing code that I think TDD will take away, for example. guessing and then working out mistakes can be a common approach that doesn't quite cut it down if you're using the strict form of TDD.

+1


source


The first thing that caught my attention was, "Test code is code anyway." I mean, wow.

Of course, the opposite is true with TDD. Your tests will become your regression firewall and allow you to reorganize and add functionality with confidence.

In my experience, you need to do two things that you need to implement in a sustainable (but not totally rebellious) brand culture: you need to have a practice assigned by the manager who gets it, and you need to have an engineer on the team who has done it before. ... This engineer time should be split between actual design work and mentoring, with the mentoring taken in the form of group presentation, code reviews, and (linking to) pair programming attacks to show people how this practice can be applied to the problems they are trying decide.

In addition to having worked in the past, this engineer also needs to be a qualified teacher and (because you are asking people to change, which most will perceive as a personal attack) have a non-threatening personality and approach to learning.

Good luck to you.

+1


source


It takes time and it takes (for lack of a better word) marketing. TDD (or, Unit Testing in general) will not be accepted until it is protected by someone respected by the team members.

If you are not already one of the most respected team members, you will either have to become one of them (demonstrating excellence) or focus on one or more technical leaders and turn them over to your side.

Everyone is different, of course, and you will need to figure out how to introduce TDD to different tribal leaders so that they are as open as possible to the idea.

One thing that must necessarily happen is that it needs to be made super-lightweight in order to create tests and run them. If you start in a position where people are skeptical about the benefits of TDD, then any minor bump on the road to experience it will be very de-motivating.

+1


source


See below link for an example approach to solving hello world problem with TDD

fooobar.com/questions/284004 / ...

you can take a look at the simplicity of the greeting, but see what you can do from the thought process

0


source






More articles:


All Articles