On Sat, Jul 20, 2013 at 1:29 AM, Graham Ashton <[email protected]> wrote:
> On 19 Jul 2013, at 21:52, Andrew Premdas <[email protected]> wrote: > > > Cucumber is a tool for doing BDD. If you misuse it and try and write > unit tests, or even declarative acceptance tests then, it is expensive, > however if you learn to use effectively and appropriately, i.e. do BDD > withit then you can dramatically reduce costs in lots of different ways. > > Can you elaborate on these ways? I'm genuinely interested in what it is > that people feel it gives 'em that they haven't already got from a decent > story and a good integration test. > > I think the most telling example of why cuke was used incorrectly is the Cucumber team dropping the web steps https://github.com/cucumber/cucumber-rails/blob/f027440965b96b780e84e50dd47203a2838e8d7d/History.md- I used to write very brittle cuke tests filling in boxes and so on because I just picked this up and thought it was the way to do things. The key is always be looking at the interface, at the behaviour. It's also important to note that it's always a compromise, there are no "right" answers, just things that are easier to maintain and less painful in the long run. So stay away from religious wars - everyone is wrong some of the time, and people have different needs. I recently had a gig teaching BDD to Perl devs, using the rather wonderfully named Pherkin. It really helped to be able to use a common language that the test team could express and share with the devs, and let everyone work together. If you have many teams and different skill levels then a Gherkin runner is really useful for creating a common language. I think that working on your own or just as a bunch of devs on a well defined team your needs might differ, but in larger organisations the tools are really useful and prevent misunderstandings if used properly. I dropped cucumber a while back and went 'pure' rspec, but actually when you have a test team or a client who want to express specs in a way that's actually useful these tools are great. I'm going to go back to cucumber but use it in a more focussed way. What I used to find was I would write the model tests and then write detailed tests of input forms, essentially testing the same thing (the model) twice. Now I lean towards making sure things render and that error messages are displayed for invalid input, but the *details* of those messages are in the rspec model tests. Part of the problem is people thinking agile (small A) means no specifications or documentation - it doesn't, and I think having living specs is a great idea because they will be maintained. It is a problem though, testing the UI in a way that will give you meaningful exceptions if you've done something to break it. For me that's the hard problem that cuke and other tools try to solve, but still a long way to go. Quite often running a selenium script that does the most complicated transaction you have and watching it with what Colin Densem calls a "mark 1 eyeball" is still a perfectly valid approach. The other thing I'm really struggling with is effective testing of things like Angular, Kyle Welsby did a lot of work in a project I've just rotated from using Karma, but it's pretty difficult (for me) because of the indirection and injection to work out what the hell is going on. The documentation and examples are still quite poor. Kyle did a sterling job though, so it is possible to do these frameworks BDD. Just my 2p -- 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.
