On 20 Jul 2013, at 10:54, Paul Robinson <[email protected]> wrote: > On 19 Jul 2013, at 21:01, Graham Ashton <[email protected]> wrote: > >> Sometimes though, you want to advocate is a move away from a current >> practice. How do you go about doing that? > > Ship code.
That's one way, but the success of it relative to alternatives is obviously dependent on the problem. > Developers who tell other developers they're doing it wrong without shipping > code are just whiny bitches. And developers who share the benefits of their experience without trying to do it through the medium of complete projects full of code are what, exactly? I'm thinking screencasts (with code in), blog posts (with code in), and plenty of explanatory material to develop a point. Projects that demonstrate the approach would be useful as supporting material, sure, but on their own they're not going to be a good way to introduce new ideas. > If you don't believe me, go and tell the core team of any open source tool or > framework what they're doing wrong by referencing some textbooks or academic > papers. I'm not sure where the idea of academia came from; if you think that's where I'm coming from I've communicated badly. > If YOU have a better idea of how to build applications that guides developers > into more structured thought processes, build a framework to allow them to do > that. I'd really enjoy trying it. It's a bit limiting though isn't it. It's like saying "don't come to me with an idea unless you've written some code to help me see your point". What about the idea that continually adding new API for people to learn could have a net negative impact on productivity. I'm not actually putting this idea forward (I haven't time for that debate); I'm just using it to illustrate the point. Shipping code isn't the only way to teach, and isn't always the best way. > Ruby is a community dominated by developers who are interested in trying new > things. Totally agree with you there. >> Cucumber is the most expensive (to use, in actual pounds) testing framework >> I've seen since Fitnesse. > > [citation needed] - Show us hard numbers. That doesn't tally with my > experience (or that of many others) Ditto - who are these others? How many developers really ask the question "will this test make/cost money over the lifetime of the project"? I agree that data on this would be wonderful. I don't think any of us will have enough of it. > If scenarios are written in such a way where product managers are actively > avoiding reading them, they're probably being written incorrectly. This is utter cobblers. You might just have a product manager who'd rather communicate with sketches, conversations and diagrams. They might be happy to write that marvellous (but sadly rare) thing; a good story card. You know, the sort of story card that acts as a placeholder for a conversation about a feature, with the implementation detail stored in the heads of those who were present. And when I say "a good story card" I don't mean any of this "As a user..." crap. I mean some carefully considered and well crafted text that sets the scene, explains the problem and the benefits of solving it. One of my hypotheses for the success of cucumber is that it hasn't replaced well written stories in many of the teams that like it, but that these teams didn't have them in the first place. I haven't explored it, but I do wonder. If you don't have conversations about stories, and cards to capture those conversastions, adding gherkin is clearly a win. I believe you'd get more benefit from adopting a process that involved chats with pens and a whiteboard, and well written stories. > Cucumber tests are - in part - a method to agree that developer and > stakeholder understanding and intent are clear and unified. I can see that gherkin can be a useful communication tool if you don't already have a better one. Kevin's point about whether it all needs to have steps behind it is a great one - I'd never considered that before (and has made this whole exchange worthwhile for me). It's writing the code to accompany the gherkin that's the expensive bit that I don't feel reaps anywhere near enough reward. > And whilst product managers might not jump for joy at reading Cucumber tests, > can you honestly say that those same managers would rather read unit tests? Eh? This is a strange idea. > So what you're actually saying is they don't want to read tests, even though > they need to. WTF? Clue me in here - why does a product manager need to read any tests? All they need to be confident of is that they've communicated effectively with the design and dev team, and to take a keen interest in their output. How they review that output is up to them, not you. > But if the tests are the active, accurate and up-to-date product > documentation, and they're the product managers, what does that say about > them professionally? What does it say about developers, if we think we can tell product managers how best to do their jobs? If a product manager is happy to accept the work I've done for them on some other basis, I'm very happy with that. I'll take a product manager who tries the app, then organises some acceptance and usability testing with an end user over the one who reads some pseudo english and assumes it translates to "brilliant, the devs understood me". The implication of your question is that you wouldn't. Which is weird. > Just because a product manager is bad at their job, it doesn't mean the > developer is being bad at theirs by trying to do the right thing and > encourage use of Cucumber to communicate and document product functionality. But "do the right thing and encourage use of cucumber" is doctrine, and we're back to "citation needed". Which is the nub of the problem; we don't have any data, just differing experience. > All I'd say is if your arguments for test-unit are basically the same as > DHH's, you should remember that DHH's stakeholders are probably not like > yours. I feel how I do about RSpec from personal experience, gained years before he voiced any complaints. My thoughts on it are based on the impact I've seen it have on people (developers), and the clarity of the test code they write. I'm not sure what DHH's stakeholders have to do with it. -- You received this message because you are subscribed to the Google Groups "NWRUG" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/nwrug-members. For more options, visit https://groups.google.com/groups/opt_out.
