Empfohlen
Weitere ähnliche Inhalte
Andere mochten auch
Andere mochten auch (11)
Kürzlich hochgeladen
Kürzlich hochgeladen (20)
Perils of testing
- 1. Perils of Testing and Perils of not testing A few anecdotes
- 2. David Dorward twitter @dorward CPAN DORWARD WWW http://dorward.me.uk
- 3. Testing
- 4. Why test?
- 5. Why test? To make sure code does what it should do
- 6. Why test? To make sure code does what it should do To make sure code continues to do what it should do
- 7. Why test? To make sure code does what it should do To make sure code continues to do what it should do To communicate what code should do
- 9. Perils of Tests 15:22 < t0m> Dorward: well volunteered, what was your CPAN id again? 15:23 < Dorward> Eeek 15:23 < Dorward> What have I done?! 15:23 < Penfold> made it better 15:23 < Penfold> be porud 15:23 <+mdk> t0m: nice one ++ 15:23 < t0m> Made DORWARD primary maintainer of Catalyst::View::ContentNegotiation::XHTML. 15:23 < t0m> Made DORWARD primary maintainer of Catalyst::View::TT::XHTML.
- 10. So who needs tests?
- 11. So who needs tests? Me: Can you merge this patch? It might need tweaking, I’m not an expert in that framework.
- 12. So who needs tests? Me: Can you merge this patch? It might need tweaking, I’m not an expert in that framework. Alice: Sure, we’ll tweak it.
- 13. So who needs tests? Me: Can you merge this patch? It might need tweaking, I’m not an expert in that framework. Alice: Sure, we’ll tweak it. Me: Hang on, it only works for the top level directory!
- 14. So who needs tests? Me: Can you merge this patch? It might need tweaking, I’m not 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…
- 15. Tests help developers communicate
- 16. …with each other
- 17. BDD
- 18. Behaviour Driven Development
- 20. For example Given a program that started at 1800 yesterday on BBC One When the iPlayer homepage is loaded Then that program is show at the top of the schedule
- 21. Business Reqs Designs UXD BA Feedback Scenario Design Meetings Testing Dev Who creates scenarios?
- 22. Benefits Everyone knows what everyone else means Challenge requirements Spot edge cases When you do start coding, you can just get on with it
- 23. BA Scenario Design Meetings Testing Dev Manual Automated Scenarios Tests Tests Artefacts
- 24. TDD
Hinweis der Redaktion
- \n\n
- \n\n
- I&#x2019;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&#x2019;s go for generic programmer material and talk about\n
- I&#x2019;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&#x2019;s a bit obvious.\nHow about Regression testing? Ditto.\nLet&#x2019;s talk communication. Tests are a way for developers to communicate.\nI promised anecdotes, didn&#x2019;t I? Let&#x2019;s start with one about&#x2026;\n
- &#x2026;Knowing your subject. I&#x2019;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&#x2026;\n
- &#x2026; someone has decided that I knew too much about the domain and made me the module&#x2019;s maintainer. Whoops.\n
- I wrote some code. It wasn&#x2019;t very good, but it got the point across. \nOr so I thought. A week later the directory handling portion of the code didn&#x2019;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&#x2019;t cover all the requirements.\n
- \n\n
- &#x2026;with each other. But what about non-developers?\n
- We&#x2019;ve been experimenting with BDD. I love TLAs!\n
- This one stands for Business Driven Development, and we&#x2019;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 &#x2014; 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&#x2019;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&#x2019;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&#x2019;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&#x2026;\n
- \n\n