Sh!t Developers Say: "We Need More Tests!"

Sdílet
Vložit
  • čas přidán 9. 07. 2024
  • Your software development team want to stop developing and take a fortnight to write some tests. Should you let them?
    = = = = = = = = = = = =
    New for 2024: my best-ever training:
    "How Your Agile Teams Can Achieve Predictability and Productivity WITHOUT Burnout"
    → www.developmentthatpays.com/w...
    = = = = = = = = = = = =
    Grab your FREE TDD vs BDD Cheat Sheet: www.developmentthatpays.com/c...
    Team falls foul of nasty bug. Team spends frustrating week tracking it down. Team calls timeout: "We Need More Tests!" Your Development Team have asked you if they can stop development for two weeks to write some tests. The decision is yours. What will you decide?
    This is the tale of TWO software development teams:
    - In one case, the team was given permission to take a fortnight to stop development and write tests.
    - In the other case, permission was REFUSED.
    In BOTH cases, the decision was... WRONG! Watch the video to find out why.
    Music: 260809 Funky Nurykabe: ccmixter.org/files/jlbrock44/29186
    -------------------
    22. Sh!t Developers Say: "We Need More Tests!"
    #DevelopmentThatPays
    Your Software Development Team has had a rough time of it. They've spent the best part of a week tracking down a nasty bug. And now they are feeling exposed. They want to stop developing. They want to s start writing tests. They reckon it will take at least a fortnight. The decision is yours. What do you say. Yes. Or No Not just hypothetical ----- This isn't just a hypothetical question. I've been part of not one but two teams that said "enough is a enough", and asked for the time and space to put things right. One team got a Yes. The other team got a No. BOTH decisions were, in my view, wrong. The Art of Motorcycle Maintenance ------- This is the motorbike I owned as a teenager. Is wasn't the most reliable machine. It seemed I spent about as much time fixing it as riding it. I had one key test that I'd do every time I came to ride it. I'd try to start it. I'd then go on to test... Come to think about it: that was about all I'd test. UNLESS it didn't start. Then I'd do other test: I might remove the spark plug and check that t I was getting a spark. If the spark didn't look very healthy, I might check the spark plug gap. Unit Tests --- Checking the spark plug gap is a great example of a Unit Test. It's a test of an individual component of a complex system. Like all good unit tests, it's independent of the rest of the system. (After all, the gap between here and here [the spark plug electrode gap] doesn't depend on anything else.) System Test -- Compare that with the test of "starting the motorbike". A running engine requires a huge number of components including the spark plug - to work together to produce a result. The result being a running engine. It's a great example of a "System Test". It could also be described as a Behavioural Test. A running engine is one of the behaviours that the "User" of a motorbike expects it to exhibit. It could also be described as a Blackbox Test: we didn't have to gain access to the innards of the engine to perform the test. Indeed, we didn't have to know anything a bout the inner working of the motorbike to perform it. All we need to know are (1) the inputs that need to be supplied.... fuel on neutral gear little bit of throttle operate the kick starter ..and (2) the output to look out for: the sound of the running engine. Functional Tests ---- Note that the very first test I mentioned - unscrewing the spark plug to check that I was getting a spark - is neither a Unit Test... ... nor it a System Test / Behavioural Test / Black Box Test. It falls somewhere between the two camps. Because I've unscrewed something, it's no longer a System Test (a test of the system as a whole). Nor can it be described as a Black Box Test. (We've "entered" the black box.) It's an example of a Functional Test: the expected "function" being the production of a spark. As a test it's slightly unsatisfactory: A pass doesn't indicate that the engine will start. A fail doesn't indicate the root cause of the problem. So a pass would lead us on to a System Test / Behavioural Test / Black Box Test. A fail would lead us to a (series of) Unit Test. Back to the Teams --- I still haven't told you about the two teams - the teams where one team got permission to write tests and the other didn't I'll reveal all in the next episode. But I will give you a big clue. One team asked to write Unit Tests The other team asked to write Behavioural Tests. Talk to you next time.
    • Sh!t Developers Say: "...
    • Test-Driven Development
  • Jak na to + styl

Komentáře • 4