Perils of testing

  • 815 views
Uploaded on

I gave a 5 minute talk on using tests and designing tests as a means to facilitate communication of requirements. …

I gave a 5 minute talk on using tests and designing tests as a means to facilitate communication of requirements.

These are the slides. Hopefully I'll have time to update them as they may not make a great deal of sense without the talk itself.

More in: Technology , Education
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
815
On Slideshare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
1
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide
  • \n\n
  • \n\n
  • I’ve been spending the last year writing lots and lots of JavaScript and almost no Perl. Which gave me some trouble coming up with a talk for LPW! So let’s go for generic programmer material and talk about\n
  • I’m going to talk about that oh so thrilling subject of testing.\n
  • So, why do we test?\nTo make sure code does what it should do? That’s a bit obvious.\nHow about Regression testing? Ditto.\nLet’s talk communication. Tests are a way for developers to communicate.\nI promised anecdotes, didn’t I? Let’s start with one about…\n
  • …Knowing your subject. I’ve spent quite a lot of time learning about exciting things like HTML, XHTML and content negotiation. Which led me to spotting a couple of limitations with the way a module that dealt with that sort of thing worked. IRC not being the best place to try to explain all the intricacies, I wrote some tests instead and the next thing I knew…\n
  • … someone has decided that I knew too much about the domain and made me the module’s maintainer. Whoops.\n
  • I wrote some code. It wasn’t very good, but it got the point across. \nOr so I thought. A week later the directory handling portion of the code didn’t work.\nIt did pass all the tests though, but since I was the only one involved who knew all the use cases, they didn’t cover all the requirements.\n
  • \n\n
  • …with each other. But what about non-developers?\n
  • We’ve been experimenting with BDD. I love TLAs!\n
  • This one stands for Business Driven Development, and we’re probably doing it wrong, but we are finding it helpful.\n
  • The basic idea is to break down the requirements into small scenarios that describe preconditions, actions and outcomes — in plain English that everyone can understand. Developers, designers, managers, everyone.\n
  • So a practical example, which I made up based on the main BBC iPlayer website (not a project I work on but one that many of you will recognise)\n
  • There are issues with that example, but first there is the question of who writes them? Well, it doesn’t really matter who writes them down, the important thing is that they are a collaborative process. One of the benefits of scenarios is that they provide a focus for discussion. In our team, a couple of developers sit down with a tester and a business analyst and hammer out the scenarios together.\n
  • Everyone knows what everyone else means. Discussions about requirements reduce problems such as a word having a different meaning to developers then it does to designers. Measure twice, cut once. There is little as boring as redoing a piece of work because the requirements were miscommunicated. \nA forum to challenge requirements; some of us have no problem shouting when we see a requirement or a design that doesn’t make sense, but this gives everyone a safe environment to raise those concerns. And it helps spot the edge cases as it gets every mind on the job. The program that starts at 1800 should be at the top? What if a program runs 1730 to 1830? What if the channel doesn’t broadcast at 6pm?\n
  • And you get scenarios, which are basically tests written in plain English. But not just plain English, it is structured and therefore rather easier to translate into code for automated tests. The rest is just…\n
  • \n\n

Transcript

  • 1. Perils of Testing andPerils of not testing A few anecdotes
  • 2. David Dorward twitter @dorward CPAN DORWARD WWW http://dorward.me.uk
  • 3. Snow caused a fire on the railway
  • 4. Testing
  • 5. Why test?
  • 6. Why test?To make sure code does what it should do
  • 7. Why test?To make sure code does what it should doTo make sure code continues to do what it should do
  • 8. Why test?To make sure code does what it should doTo make sure code continues to do what it should doTo communicate what code should do
  • 9. Knowing your subject
  • 10. Perils of Tests15:22 < t0m> Dorward: well volunteered, what was your CPAN id again?15:23 < Dorward> Eeek15:23 < Dorward> What have I done?!15:23 < Penfold> made it better15:23 < Penfold> be porud15:23 <+mdk> t0m: nice one ++15:23 < t0m> Made DORWARD primary maintainer ofCatalyst::View::ContentNegotiation::XHTML.15:23 < t0m> Made DORWARD primary maintainer ofCatalyst::View::TT::XHTML.
  • 11. So who needs tests?
  • 12. So who needs tests?Me: Can you merge this patch? It might need tweaking, I’mnot an expert in that framework.
  • 13. So who needs tests?Me: Can you merge this patch? It might need tweaking, I’mnot an expert in that framework.Alice: Sure, we’ll tweak it.
  • 14. So who needs tests?Me: Can you merge this patch? It might need tweaking, I’mnot an expert in that framework.Alice: Sure, we’ll tweak it.Me: Hang on, it only works for the top level directory!
  • 15. So who needs tests?Me: Can you merge this patch? It might need tweaking, I’mnot an expert in that framework.Alice: Sure, we’ll tweak it.Me: Hang on, it only works for the top level directory!Bob: It passes the tests that Alice wrote though…
  • 16. Tests help developers communicate
  • 17. …with each other
  • 18. BDD
  • 19. Business Driven Development
  • 20. ScenariosGivenWhenThen
  • 21. For exampleGiven a program that started at 1800 yesterday on BBC OneWhen the iPlayer homepage is loadedThen that program is show at the top of the schedule
  • 22. Business Reqs Designs UXD BA Feedback Scenario Design Meetings Testing DevWho creates scenarios?
  • 23. BenefitsEveryone knows what everyone else meansChallenge requirementsSpot edge casesWhen you do start coding, you can just get on with it
  • 24. BA Scenario Design Meetings Testing DevManual Automated Scenarios Tests Tests Artefacts
  • 25. TDD