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.
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.
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…
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
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