Representative Unit Test


  • :belt_onion:

    During a code review, my colleague detected this 'assert' block in one of the unit test, written by one of our offshore developers:

    
    [i]''snipped the arrange and act parts[/i]
    
    For i = 0 To cashAdvice.Balances.Count - 1
    
    If cashAdvice.Balances(i).UpdateTypeCode = "U" Then
       Assert.AreEqual("U", cashAdvice.Balances(i).UpdateTypeCode)
    Else
       Assert.AreNotEqual("U", cashAdvice.Balances(i).UpdateTypeCode)
    End If
    


  •  This is good practice. You never know when some pesky cosmic ray might change the value of UpdateTypeCode.


  • Trolleybus Mechanic

    @bjolling said:

    During a code review, my colleague detected this 'assert' block in one of the unit test, written by one of our offshore developers:

    ''snipped the arrange and act parts
    

    For i = 0 To cashAdvice.Balances.Count - 1

    If cashAdvice.Balances(i).UpdateTypeCode = "U" Then
    Assert.AreEqual("U", cashAdvice.Balances(i).UpdateTypeCode)
    Else
    Assert.AreNotEqual("U", cashAdvice.Balances(i).UpdateTypeCode)
    End If

     

    Obviously cashAdvice.Balances are not thread safe. There's no guarantee .UpdateTypeCode will still be "U" after the if statement.

     



  • @bjolling said:

    During a code review, my colleague detected this 'assert' block in one of the unit test, written by one of our offshore developers:

    ''snipped the arrange and act parts
    
    For i = 0 To cashAdvice.Balances.Count - 1
    
    If cashAdvice.Balances(i).UpdateTypeCode = "U" Then
       Assert.AreEqual("U", cashAdvice.Balances(i).UpdateTypeCode)
    Else
       Assert.AreNotEqual("U", cashAdvice.Balances(i).UpdateTypeCode)
    End If
    

    Well, that's one way to ensure your asserts always pass.





  • Yeah son, it's gonna be one of those code reviews...



  • Forgot the important part of the red-green-refactor: start out RED.

    Anyone can write a test that can trivially pass; it's the good guys who write a test that fails!



  • You get to work with offshore devs who even attempt unit tests? Christ I'm jealous.



  • @DrPepper said:

    Forgot the important part of the red-green-refactor
     

    "The code refactoror's secret weapon: Duct tape!"

    "If your code review can't find you handsome, it should at least find you handy."

    "If it ain't broke, you're not trying hard enough."

     



  • @DCRoss said:

    @DrPepper said:

    Forgot the important part of the red-green-refactor
     

    "The code refactoror's secret weapon: Duct tape!"

    "If your code review can't find you handsome, it should at least find you handy."

    "If it ain't broke, you're not trying hard enough."

     

    Shut up Harold.


  • :belt_onion:

    @Smitty said:

    You get to work with offshore devs who even attempt unit tests? Christ I'm jealous.

    We went through a lot of pain and effort to explain what unit tests are, why we want them and how it helps THEM. But for them it's just another deliverable.

    They refuse to understand how unit tests can actually help them delivering better code so they write them only after we reject the code review. And then it's too late and the code review process become a game of table tennis that can go on for many days until the code is acceptable enough to let is pass.

    It still hurts



  • @bjolling said:

    We went through a lot of pain and effort to explain what unit tests are, why we want them and how it helps THEM. But for them it's just another deliverable.

    They refuse to understand how unit tests can actually help them delivering better code so they write them only after we reject the code review. And then it's too late and the code review process become a game of table tennis that can go on for many days until the code is acceptable enough to let is pass.

    It still hurts

     

    I used to have the same problem....Then we changed the contract. The first deliverable was Interfaces and UnitTests. Once those were approved, they were authorized to write the actual implementations of the interfaces. Yes, we ended up with more interfaces than really necessary/appropriate; but it was an excellent tradeoff and the "silly" interfaces could be easily factored out late in the game.

     

     

     



  • @bjolling said:

    We went through a lot of pain and effort to explain what unit tests are, why we want them and how it helps THEM. But for them it's just another deliverable.

    They refuse to understand how unit tests can actually help them delivering better code so they write them only after we reject the code review.

    It's hard to get people who are used to cheap labor to buy into the idea of writing code that saves manual testing. From their point of view, you are doing something expensive to avoid doing something cheap. Also, to them, it's easy to round up 20 people and get a testing effort started, but it's hard to train developers to do proper unit testing because the amount of employee churn multiplies training costs by a large factor.



  • @thecpuwizard said in Representative Unit Test:

    @bjolling said:

    We went through a lot of pain and effort to explain what unit tests are, why we want them and how it helps THEM. But for them it's just another deliverable.

    They refuse to understand how unit tests can actually help them delivering better code so they write them only after we reject the code review. And then it's too late and the code review process become a game of table tennis that can go on for many days until the code is acceptable enough to let is pass.

    It still hurts

    I used to have the same problem....Then we changed the contract. The first deliverable was Interfaces and UnitTests. Once those were approved, they were authorized to write the actual implementations of the interfaces. Yes, we ended up with more interfaces than really necessary/appropriate; but it was an excellent tradeoff and the "silly" interfaces could be easily factored out late in the game.

    How likely do you think it was that they wrote the implementation first, wrote unit tests to match their implementation, and then sent you those unit tests?


  • 🚽 Regular

    @djls45 said in Representative Unit Test:

    How likely do you think it was that they wrote the implementation first, wrote unit tests to match their implementation, and then sent you those unit tests?

    And they must have taken 4 years to do it too.


  • FoxDev

    @djls45 said in Representative Unit Test:

    @thecpuwizard said in Representative Unit Test:

    @bjolling said:

    We went through a lot of pain and effort to explain what unit tests are, why we want them and how it helps THEM. But for them it's just another deliverable.

    They refuse to understand how unit tests can actually help them delivering better code so they write them only after we reject the code review. And then it's too late and the code review process become a game of table tennis that can go on for many days until the code is acceptable enough to let is pass.

    It still hurts

    I used to have the same problem....Then we changed the contract. The first deliverable was Interfaces and UnitTests. Once those were approved, they were authorized to write the actual implementations of the interfaces. Yes, we ended up with more interfaces than really necessary/appropriate; but it was an excellent tradeoff and the "silly" interfaces could be easily factored out late in the game.

    How likely do you think it was that they wrote the implementation first, wrote unit tests to match their implementation, and then sent you those unit tests?

    Damnit @wharrgarbl! doing this as yourself wasn't enough?! You have to use alts too?!

    :kermit_flail:



  • @djls45 said in Representative Unit Test:

    How likely do you think it was that they wrote the implementation first, wrote unit tests to match their implementation, and then sent you those unit tests?

    Very unlikely. Largely because of the timing [they had one 2 week sprint to deliver the interfaces and tests]



  • @accalia I am more impressed that 4 years later, @TheCPUWizard still remembers enough to continue the discussion as if it was yesterday!



  • @remi said in Representative Unit Test:

    @accalia I am more impressed that 4 years later, @TheCPUWizard still remembers enough to continue the discussion as if it was yesterday!

    Some things leave a lasting impression. The real world situation that my post from 4 years ago actually happened nearly 6 years ago - but it is still on top of mind as the "learning experience" has influenced how we write contracts with external developers to this day (details have changed over the past 6 years).



  • @thecpuwizard said in Representative Unit Test:

    Some things leave a lasting impression.

    And these are usually the ones we want to share here... I know the feeling!


  • FoxDev

    @remi said in Representative Unit Test:

    @accalia I am more impressed that 4 years later, @TheCPUWizard still remembers enough to continue the discussion as if it was yesterday!

    agreed. impressive.

    /me hands @TheCPUWizard a bottle of Jameson


Log in to reply