locked
1 developer writing unit tests for whole team?

    Question

  • hi,

    i'm a java developer with 10 years programming experience. although it hasn't always been mandated on some projects i have worked on, i have always written unit tests (junit) for my own code even though most of my fellow team members didn't.

    i recently joined a new team. i was one of the last to join the team. so, the "good" (most sought-after) tasks had already been assigned to full-time permy developers or contractors that joined the project weeks before i joined. i am assuming that due to a combination of timing and my previous experience with unit tests, i was assigned the illustrious task of writing all the unit tests for all the other developer's code! oh what fun!

    although i know i am better qualified to work on other coding tasks (testing is not my forte); i'm not so full of myself that i think a testing task is beneath me. i am happy to help the team out however i can; and i intend to do the best that i can to complete the task i've been assigned. besides, they're paying me a pretty penny, and i get paid regardless of what task i'm assigned ;¬)

    that said, i do not think it is a good idea for one developer to be writing the unit tests for even one other developer, not to mention a whole team of developers (there's 10 of them)!

    i'm planning on making a case to my manager (who is kind of green at managing sofware dev projects) that this is not a good path to go down for several reasons:

    1) it's extremely risky! 2) it's very unorthodox! 3) i'm not a "tester", i'm a coder!

    to help me make my case to my manager, my questions to the forum are:

      1. how common is it to have one member of a dev team write the unit tests for code written by other members of the team?

      2. what are some of the risks involved in this approach?

      3. what would you do in the same situation?

      4. what does this say about the manager that assigned the task?

    thanks in advance for your replies.


    ciao,
    sun_certified
    Thursday, October 18, 2007 9:36 PM

Answers

  • The role looks like it's similar to the SDE/T in Microsoft - that's a Software Development Engineer in Test. Microsoft usually has close to a 1 to 1 ratio of SDEs to SDETs, but it varies a bit from product to product, as well as in the various stages of the lifecycle - when getting closer to ship time, more SDETs are brought in.

     

    You might try to take something of a mentoring role around the issue of unit testing, but get your manager on board first. If more of the other devs start unit testing, quality will probably go up, and releases will eventually come quicker. This is something that you're manager can probably get behind.

     

    Keep in mind that team makeup is context dependent - there is no "best" approach for all environments, despite what some agilists say (I try to be as agile as is possible within a given context, but that's when I'm in the manager's position).

     

    Best of luck.

    Friday, October 19, 2007 7:46 AM
  • I agree with your first point "it's extremely risky", because 1 to 10 is a very bad ratio. As Udi points out, Microsoft tries to keep about a 1 to 1 ratio, although the SDETs' time isn't 100% focused on writing unit tests, they are also writing tools, doing ad-hoc testing, etc. With a 1 to 10 ratio, you will not be able to get the best test coverage on all the code paths; there will be a lot of areas that you just don't have the time to cover. You should definitely push to either have the other developers write unit tests and/or hire more resource if they are serious about the quality.

     

    Some teams at Microsoft will have (or at least encourage) developers provide some basic unit tests. Then the SDETs will write a much more complete/exhaustive set of test code. In my experience, the good developers will do unit tests anyway. Getting everybody to contribute must be driven by the managers and cultivated through the culture.

     

    Friday, October 19, 2007 4:22 PM
    Moderator

All replies

  • The role looks like it's similar to the SDE/T in Microsoft - that's a Software Development Engineer in Test. Microsoft usually has close to a 1 to 1 ratio of SDEs to SDETs, but it varies a bit from product to product, as well as in the various stages of the lifecycle - when getting closer to ship time, more SDETs are brought in.

     

    You might try to take something of a mentoring role around the issue of unit testing, but get your manager on board first. If more of the other devs start unit testing, quality will probably go up, and releases will eventually come quicker. This is something that you're manager can probably get behind.

     

    Keep in mind that team makeup is context dependent - there is no "best" approach for all environments, despite what some agilists say (I try to be as agile as is possible within a given context, but that's when I'm in the manager's position).

     

    Best of luck.

    Friday, October 19, 2007 7:46 AM
  • I agree with your first point "it's extremely risky", because 1 to 10 is a very bad ratio. As Udi points out, Microsoft tries to keep about a 1 to 1 ratio, although the SDETs' time isn't 100% focused on writing unit tests, they are also writing tools, doing ad-hoc testing, etc. With a 1 to 10 ratio, you will not be able to get the best test coverage on all the code paths; there will be a lot of areas that you just don't have the time to cover. You should definitely push to either have the other developers write unit tests and/or hire more resource if they are serious about the quality.

     

    Some teams at Microsoft will have (or at least encourage) developers provide some basic unit tests. Then the SDETs will write a much more complete/exhaustive set of test code. In my experience, the good developers will do unit tests anyway. Getting everybody to contribute must be driven by the managers and cultivated through the culture.

     

    Friday, October 19, 2007 4:22 PM
    Moderator
  • The role that you have been assigned is not similar to the role of the average SDET at Microsoft. As Josh says, an SDETs time isn't 100% focused on unit testing; in fact the average SDET at Microsoft is generally not involved at writing unit tests because we expect out developers to write unit tests.

     

    So, let's focus on your specific assignment. You indicate you are only focused on unit testing and assigned to test at the integration and/or system level (which is where the majority of SDETs at Microsoft design, develop and exeucte tests). And you state that you have a lot of experience (compared to your teammates) writing unit tests.

     

    Based on your post, we probably agree that unit testing is a best practice that can identify defects earlier in the process. We can probably also agree that many developers (especially those who have not done much unit testing) may not develop effective unit tests. So, is your job really as simple to write the unit tests for 10 dev's, or is your role to provide a greater value to the team and the organization by acting as a mentor to the 10 developers and sharing your knowledge of the value of unit tests and how to write effective unit tests?

     

    Some senior SDETs at Microsoft do work with their dev counterparts to teach them how to write better unit tests. Perhaps your manager wants to use your skill, knowledge, and experience as a means to identify defects earlier in the lifecycle, reduce costs, and to strengthen and improve the development effort (by eventually instilling a culture of unit testing among the developers). To paraphrase Andrew and Hunt in their book Pragmatic Unit Testing, developers get paid to write code that works and the only way they can demonstrate that at least at a basic level is to perform unit testing.

     

    Is this approach unconventional...sure, but I suspect a lot of folks said the agile programming approach is unconventional. What does it say about the manager...it could say the manager is best utilizing the skills and knowledge of the team members to benefit the project. The risks are many...perhaps you are not up to the task of mentoring 10 people, perhaps the management doesn't support cultural change, perhaps you don't want to learn yourself about testing techniques and methods that could make your own unit tests even better, etc.

     

    But, rather than looking at this as "I'm not a test, I'm a coder" perspective, I suggest viewing this as a "I'm an experienced and confident coder who is going to teach less experienced, less skillful coders how to become better at their jobs."

    Sunday, October 21, 2007 7:12 PM