Force module testing for developers

Question

First, a little background. The company I work with writes web-based software, which is a hosted solution for our customers (for example, ASP (Application Service Provider)). We implement agile methods such as Scrum and sprint to create new features for our product.

I am a supporter of TDD (Test Driven Design), and as part of what I supply in the sprint, I always write tests and I always integrate them into the assembly (i.e. ccnet); however, other developers are not following this practice and are not being implemented.

Is it good practice forcing a development team to provide unit tests as part of what comes in a sprint?

Answer 1

Forcing anything to someone is not good practice in my opinion. I would show them the benefits of TDD at every opportunity I get. This should automatically force the rest of the team to voluntarily apply TDD.

Answer 2

If you are not an authority, the best thing you can do is to convince them of the value of the test suite.

It is very difficult to get developers to see the light on this issue if they do not see that it is done correctly.

Try to connect with another developer and show them the advantages and clarity that arise when writing FIRST tests. If you do not, they will most likely write all their code, earn money, and then write tests. Thus, from their point of view, it will be just an additional task that will not help them achieve a result.

Also keep in mind that people often do not understand how to write good tests. Moreover, some do not know how to use tools like jmock, which can lead to them getting stuck and refuse to write a test.

Answer 3

You do not need to test lip modules; you want comprehensive unit testing. This is not something that can be forced. What you need to do is influence your teammates over time to see the benefits of unit testing and develop a unified test culture.

First you need to understand that different people change for different reasons. In terms of Crossing the Chasm, seers will use new methods because they are better, but pragmatists accept new methods either because they solve the problem / currently have it or because everyone else accepts it.

Your mission then is to show how unit testing can solve the pain your team is experiencing. When you win people in turn, you can ultimately reach a tipping point when unit testing is the norm, and everyone agrees. However, if you cannot relate unit testing to the pain your team is experiencing, your efforts to convince them will most likely fail.

Answer 4

Given that unit testing improves the quality of code and software in the long run, I would say that, yes, it is good practice for your developers to provide unit tests - whether it be part of a sprint or not.

Two main obstacles to unit tests that I have seen:

• developers do not understand: "why do we need to write more code for testing?"
• "we don’t have time to write unit tests"

To answer the first question, you will need to provide some kind of demonstration / formation, I suppose; if you can get developers to understand why unit tests are useful, they will like them and use / develop them; but they need to understand why they are useful: if you are not their boss, you cannot force people to develop unit tests.
And, even if you are their boss, they probably won’t do the best job if they are forced to: unit testing is often done better if people understand why and how!

To answer the second question ... Well, you obviously need your developers to get "special" time for developing unit tests; this may mean less time for manual testing, by the way.

Another thing: it is difficult to find out “what to check” and “how to test”: you will need to explain / demonstrate it to your colleagues: some things cannot be tested, some things do not need to be, and some things are not “checked per unit” - well, I suppose if you are not very well designed ^^

Answer 5

I have held this position on many jobs and contracts in the past, so I finally became disillusioned and accepted the darkness, defending Development Driven Development .

I found that when most managers use XP, they cuddle, throwing out documentation, not doing TDD. The programmers of most teams receive rewards for fast hacks that get out of line, and one manager of about ten people who have the courage to stand in front of senior management as a supporter of the overall quality of the product, and not the bottom -line-for-this-quarter way of doing business . After all, most software jobs that pay are sponsored by a corporation, and Freud has proven that corporations are insane.

Or at least he should have.

Answer 6

There is an excellent Joel on Software article titled Getting Things When You Are Just Grunt . Its strategies used for unified testing will be as follows:

• Just do it

  Most importantly, I think. Write tests regularly, do not do it as if you yourself consider them as an insignificant part of the development.

• Harnessing the Power of Viral Marketing

  If you see an error in someone’s code, write a test that runs it and presents it to him. Perhaps he sees your point.

• Create Pocket Excellence

  Identify team members who are open to this idea, but are not quite sure how to work with unit tests and set up several test classes until each of them knows how to do it. Then turn to the others. Things are much easier to install once you are no longer the only ones.

• Neutralize bozos

  There will be team members who are almost impossible to get to write tests. Perhaps you need to deal with this by regularly breaking your code into a new commit, and then indicating that since they have no tests, it was difficult for you to notice.

Answer 7

it depends on your version control, but there is version control software that allows you to run scripts before registration or before merging with the production branch. and it will not allow the developer to check whether the device’s testing has completed.

Answer 8

Talk to your manager first. If he is convinced that testing is good, add a coverage test to your build system. If your device’s test coverage falls below a certain level, you can treat it as a failed build. This gives your colleagues an assessment, a way to see when the verified code fails to execute.

In your case, NCover seems to integrate perfectly into CC.NET .

Answer 9

Not. In my experience, TDD is not so useful in practice. I sometimes use it for really general fundamental classes (such as geometry or general data structures) that naturally lend themselves to automatic testing. But for user interface or business logic components, I find that this is more of a problem than it costs.