Loading ...
Sorry, an error occurred while loading the content.

Re: [scrumdevelopment] Convince the team of writing unit tests even if you have got integration tests

Expand Messages
  • Steve Crago
    I know this isn t politically correct. However, I have used it and you d be surprised at the reactions you get. Tell your developer s that if they do not want
    Message 1 of 8 , Jun 24, 2013
    • 0 Attachment
      I know this isn't politically correct.  However, I have used it and you'd be surprised at the reactions you get.

      Tell your developer's that if they do not want to have unit tests then they will have to pay $1,000.00 for every defect that results from the code they've tossed over the wall to the test team, regardless of the severity and regardless if it's caused by "old" or "legacy" code as they touched it and it now belongs to them.

      See how many takers you have … my team changed their minds real quick and started unit testing.

      Cheers,

      Steve



      On Jun 24, 2013, at 2:31 PM, Markus Gaertner <mgaertne@...> wrote:

       

      Hi Martin,

      if you happen to be able to argue based on logic, hand each of them a copy of Weinberg's Perfect Software... and other illusions about testing. Make sure to point them out especially to the Composition Fallacy:
      "Skipping unit testing as redundant because system testing will catch all the bugs." (this also applies to tests in folklore referred to as "integration tests" (on a side note: I hate that term, and we should get rid of it, but I don't have a better name to offer, unfortunately.)).

      If your developers no longer constrain their thinking by logic, then I would show them over a long period of time that writing unit tests helps me in the long run deal with those new requirements that come up every time. Simple work the way you are convinced, and show them in the long run that you can still deliver based on your unit tests. Stop arguing, start doing.

      Best
      Markus


      On Fri, Jun 21, 2013 at 8:53 AM, <m.schneider@...> wrote:
      Hi,

      I'm working with a new team and try to convince the team members that it
      is important to write unit tests and have got covered at least methods
      which consist of logic. Also it is important (for me) to write unit
      tests for existing code if you touch it and it is not covered yet.
      Unfortunately some of the team members tell me that they do not want to
      write unit tests because we have got integration tests and those will
      test the correctness of the code and with that make unit tests
      unnecessary.

      What can I tell those guys why it is important to write unit tests even
      if you have got integration tests?

      Thanks,
      Martin



      ------------------------------------

      To Post a message, send it to:   scrumdevelopment@...
      To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...! Groups Links

      <*> To visit your group on the web, go to:
          http://groups.yahoo.com/group/scrumdevelopment/

      <*> Your email settings:
          Individual Email | Traditional

      <*> To change settings online go to:
          http://groups.yahoo.com/group/scrumdevelopment/join
          (Yahoo! ID required)

      <*> To change settings via email:
          scrumdevelopment-digest@yahoogroups.com
          scrumdevelopment-fullfeatured@yahoogroups.com

      <*> To unsubscribe from this group, send an email to:
          scrumdevelopment-unsubscribe@yahoogroups.com

      <*> Your use of Yahoo! Groups is subject to:
          http://docs.yahoo.com/info/terms/




      --
      Dipl.-Inform. Markus Gärtner
      Author of ATDD by Example - A Practical Guide to Acceptance Test-Driven Development


    • David Karr
      Integration tests are often fragile, because they often depend on test data resources. When integration tests fail, it s often ambiguous whether it really
      Message 2 of 8 , Jun 24, 2013
      • 0 Attachment
        Integration tests are often fragile, because they often depend on test data resources.  When integration tests fail, it's often ambiguous whether it really represents a test failure, or simply obsolete data.  Because of this, integration tests require more maintenance, and are often ignored.

        Unit tests run very quickly, and should run as part of the normal developer build.  Test failures come quickly, resulting in a shorter feedback cycle.

        An additional value of unit tests is as documentation of the "code under test".  New developers can read the unit tests to understand the requirements of the business logic in question.  This doesn't work as well with integration tests.


        On Mon, Jun 24, 2013 at 1:52 PM, Adam Sroka <adam.sroka@...> wrote:
         

        Problems with integration tests:

        1) They take longer to execute. This makes the feedback loop slower which means they run less often. 

        2) They consume more resources to execute. You may need beefier hardware and/or you may have problems doing other things while they run. 

        3) They often have complex dependencies, e.g. running web servers, databases, message buses, etc. These consume resources and may cause intermittent failures that are hard to diagnose. 

        4) They are uninformative, i.e. when they fail it may take considerable time/effort to find out why. 

        5) They touch many parts of the system at once. Assuming decisions are made in each of these parts it may take a very large number of tests to exercise all meaningful permutations. 


        On Fri, Jun 21, 2013 at 2:53 AM, <m.schneider@...> wrote:
         

        Hi,

        I'm working with a new team and try to convince the team members that it
        is important to write unit tests and have got covered at least methods
        which consist of logic. Also it is important (for me) to write unit
        tests for existing code if you touch it and it is not covered yet.
        Unfortunately some of the team members tell me that they do not want to
        write unit tests because we have got integration tests and those will
        test the correctness of the code and with that make unit tests
        unnecessary.

        What can I tell those guys why it is important to write unit tests even
        if you have got integration tests?

        Thanks,
        Martin



      • Ron Jeffries
        Hi Martin, ... First of all, I note that logic rarely convinces people. That said ... I assume that your defect list is quite short. (One or two known
        Message 3 of 8 , Jun 24, 2013
        • 0 Attachment
          Hi Martin,

          On Jun 21, 2013, at 2:53 AM, m.schneider@... wrote:

          I'm working with a new team and try to convince the team members that it
          is important to write unit tests and have got covered at least methods
          which consist of logic. Also it is important (for me) to write unit
          tests for existing code if you touch it and it is not covered yet.
          Unfortunately some of the team members tell me that they do not want to
          write unit tests because we have got integration tests and those will
          test the correctness of the code and with that make unit tests
          unnecessary.

          What can I tell those guys why it is important to write unit tests even
          if you have got integration tests?

          1. First of all, I note that logic rarely convinces people. That said ...
          2. I assume that your defect list is quite short. (One or two known defects.) Otherwise, your team might want to have more and better tests.
          3. Of course you have coverage measurements and your integration tests cover essentially 100% of the system.
          4. I assume that your integration tests take only a few minutes to run, can be run any time anyone wants, and that they always report zero errors, so that in the rare event someone DOES make a mistake, they can find out in seconds that they've done something wrong? If they take a long time to run, or are already reporting lots of errors, your team might want to have more and better tests.
          5. I suppose that when an integration test fails, it is immediately clear which individual's (or pair's) code has failed, and where in the code base the error is. If the existing tests don't say exactly where the error is, your team might want to have more and better tests.
          Let's recap. If …

          • Your product has only a few known defects;
          • Your integration test coverage is approximately 100%;
          • Your tests take just a few minutes to run;
          • Your tests can be triggered by any programmer at any time;
          • Your tests immediately identify what part of the code has failed.

          … then you don't need any more testing.


          Ron Jeffries
          www.XProgramming.com
          Sometimes I give myself admirable advice, but I am incapable of taking it.
          -- Mary Wortley Montagu



        Your message has been successfully submitted and would be delivered to recipients shortly.