What would you recommend to start learning and applying BDD on a casual game development studio?
While I can't speak to using BDD specifically with games, I can't pass up the opportunity to introduce you to this excellent article:
http://www.code-magazine.com/article.aspx?quickid=0805061&page=1
One of my favorite overviews of BDD as a development methodology. Covers the process very well, and explains creating specifications via concern, context, and observations very nicely.
I also highly recommend using xUnit.NET and Moq as your testing platform (if you are lucky enough to be using .NET, that is). The following article provides an excellent specification-centric testing platform built on xUnit.NET, and follows the tennent of single-assertion-per-test-case very nicely:
http://iridescence.no/post/Extending-xUnit-with-a-Custom-ObservationAttribute-for-BDD-Style-Testing.aspx
Depending on your language and learning preference:
The RSpec Book talks about BDD using Ruby, RSpec and Cucumber. It is an EXCELLENT source for learning about the Concentric circles of BDD.
jrista's link to Bellware's article in Code Magazine is another EXCELLENT resource.
Just remember that BDD is about describing requirements/specifications so succinctly that they are executable. Then write the code that satisfies that spec. Rinse and repeat.
Hope this helps.
Lee
I think there are two aspects of BDD to consider if you want to use it. One part is "BDD is TDD done right", i.e. the way to learn TDD is not to think of it as writing tests first but to write behaviour/specifications first.
The second part is that BDD, as implemented in JBehave is a side that was long forgotten in the .Net community I think. Only recently NBehave implemented something similar to what JBehave is i.e. a way to have non-programmers writing the specifications (behaviours) for you. This only applies to pretty high level behaviours as user stories and scenarios so you can't do only this. You need the "first part BDD" and/or TDD too. The second type of BDD I describe is a complement to "regular TDD".
Related
I am trying to get started with BDD and found a view blog posts about MSpec and SpecFlow. I'm currently not quite sure when I would use which and what the advantages/disadvantages of either framework are.
Looking at the documentation it seems that MSpec uses the context specification style whereas SpecFlow uses Given/When/Then style. I don't really mind either but I would like to know if there are any pitfalls to watch out for further down the track when the project/test suite grows.
Basically some real world advice/feedback of someone who uses it in their every day work would be great.
So I've used both.
I like the mspec workflow in away because its an easier sell for me to speak to users and say.
"When logging in"
"I should return to the page I requested"
When I've worked for organisations that have bought more into active collaboration (read agile) I've used the Given When Then pattern. That organisation was used to user stories so they were used to a more rigid style of specification. Also we were using more than one tool to feed the specs into. so the 'text only' feature files could be reused between tools.
In my own projects I use SpecFlow for the 'outside' and 'mspec' for inside of tests.
If I was to give someone advice it would be to use specflow if non technical people are writing the outside specs and mspec if a developer is writing the.
Bad points:
Mspec is class explosion
SpecFlow is a slower workflow
Good points:
Mspec is a more natural language
Specflow is better for reusability for steps.
The bottom line is they work well together.
One disadvantage of mspec is you cannot run in parallel whereas with specflow runner you can. That is a big performance issue.
Im a beginner when it comes to TDD and BDD.
This is what I know:
To use TDD in Rails I use it's built-in unit-, functional and integration tests.
To use BDD in Rails I use Cucumber.
So are these two different techniques that shouldn't be used together?
If I use TDD, then I shouldn't use BBD/Cucumber and vice versa?
Please enlighten me on this topic.
Thanks
Not that I'm a genius at this but here's my humble answer.
Cucumber is great for outline the behavior of your site, incorporating the business solutions and the code together and developing the site properly from it.
Then after this is complete, you create Rspecs to test how data holds in your MVC. Rspec is great for models.
I've been recommended using Factory-Girl for testing controllers.
In conclusion, using all of these provides a very rounded series of tests to ensure that first your business solutions are being met, and second that your architecture can withstand the many angles that can be tested with rspec and factory-girl.
I've found that getting the right mix of what to when and why was the toughest part, given that there is often too much information on the net. A good blog post is Outside in BDD which takes you on a journey of testing using Cucumber and RSpec.
The author, Sarah Mei, explains the flow that a developer would undertake to use BDD/TDD and highlights some caveats on testing Controllers, Models and Views.
I tend to agree that Rspec is good for the models, more so when you have custom behaviour that is beyond what Rails gives you out of the box. This comes out in the RSpec & Cucumber books, it's just that it takes a while to find that gem of information about testing what, when and why !
I'd like to enable the business analysts to be able to write all of their specs for features, scenarios and steps that is Cucumber friendly using Gherkin.
I've read some of the basic info on the github site for Cucumber and from doing a quick Google search but wanted to know if there were recommended resources for getting non-technical folks to be able to write comprehensive BDD using Gherkin (I assume that's the preferred language for Cucumber tests to be created in).
Thanks.
What I did with the business analysts in our company was to teach them the structure by giving them the keywords: Given, When, Then, And for Scenarios and In order to, As a and I want to for Features.
Then I gave them a simple example and told them to write down their own features as they thought they should be written. Surprisingly enough the structure was self explanatory and the features they wrote became a great start.
The only big problem was that they had contained to much logic in each scenario step. I solved that by iteratively asking "why?" which in most cases revealed the core functionality they were after and we re-wrote the scenarios accordantly.
By giving them the guidelines and letting them write the features themselves they got their hands dirty and were forced to think about what they wrote. Today they have a much better understanding and the "why?" iterations are not that common anymore.
Ofcourse you need to have the business analysts and the developers to work closely together and the features the analysts write should only act as a start. Remember that the Cucumber features are just a common language between the analysts and the developers. They still need to sit together often to be able to speak with each other :)
http://cukes.info is a great resource for teaching people how to write them. Ben Mabey also made a great presentation on Cucumber at Mountain West Ruby Conference 2009.
Having just worked on an agile project using cucumber for the first time I think that the best way to learn Cucumber and Gherkin is to get your hands dirty.
I may be wrong but I get the impression from your question you are wanting to train your BAs to write Gherkin; then they will write a bunch of features and hand them to developers.
This is definitely not the way to go. It is much better to have BA's devs and users (if possible) working together to write your scenarios and build them as you go. Then you all learn together what works and what doesn't.
We tried having a BA write entire features and hand them over. We (the devs) ended up having to do major rewrites because the implementation ended up different to that originally envisioned by the BA. We also had to change the syntax of the steps and do find and replace through the whole file.
Do one scenario at a time, get it working then move on to the next. An iterative approach reduces wasted effort and makes sure you all understand how you want the app to behave.
In terms of how to write steps it is best to start with the ones that come with Cucumber and copy and adapt them as you work on your project to fit your particular application. There is no right or wrong, it is what works for you. The documentation on the cucumber sites is generally good and will be a valuable resource as you learn more.
We are teaching Gherkin (for SpecFlow) in a similar way, how mrD has described it.
I think it is very important though, that the audience is familiar with the main intention of "Specification by Example", agile requirement analysis and BDD, so we usually start discussing the background first. We also show a sample Gherkin scenario and explain the very basics (like Given/When/Then/But and tables).
Than we take a simple example story (that is quite familiar to everyone), like "add items to shopping cart" (with some orientation, of course) and let them formulate the acceptance criteria in small groups.
After that every team shows / explains their solutions and we discuss the good and bad practices that were present. After the second team, you can see almost all of the most important (good or bad) practices appearing.
I also type in the concluded solution, and show here alternative ways of describing the scenarios (background, scenario outline, etc.). If there is enough time, I also show how to automate & implement the imagined functionality based on that. This also help to understand some important rules to follow, that makes the automation much easier.
Although, I never know upfront what will happen, usually this exercise is the best part of our BDD training.
The RSpec book has a couple of chapters in it that are relevant to Business Analysts:
http://pragprog.com/book/achbd/the-rspec-book
I think the best way to learn is to start writing. Gherkin & Cucumber are easy to learn but difficult to master, so it’s important to get to practical examples as soon as possible.
While it’s important to get started by writing your first scenarios, you also need some resources to establish good habits and understand key practices. I wrote a book that could help. “Writing Great Specifications” is, I hope, a good way to learn Gherkin and Cucumber. It covers patterns and antipatterns as well as key techniques for writing great scenarios. :) If you have any questions, you can always hit me up on Twitter.
If you are interested in buying “Writing Great Specifications,” you can save 39% with the promo code 39nicieja2 :)
Other great resources:
“Specification by Example” by Gojko Adzic if you’re interested in software development processes and high-level engineering practices.
“BDD in Action” by John Smart if you don’t mind reading testing code in Java. It’s a comprehensive end-to-end view on defining and testing software requirements.
“Behaviour-Driven Development” by Liz Keogh if automated testing doesn’t ring a bell, but you want to understand how specifications with examples affect your business analysis processes.
“The Cucumber Book: Behaviour-Driven Development for Testers and Developers” by Matt Wynne and Aslak Hellesøy
“The RSpec Book: Behaviour-Driven Development with RSpec, Cucumber, and Friends” by David Chelimsky, Dave Astels, Zach Dennis, Aslak Hellesøy, Bryan Helmkamp, Dan North
Best way to learn Gherkin is to read the Behat documents first: http://behat.readthedocs.org
Then read official documents from cucumber site: https://cucumber.io/docs/reference
Also, you can read Guru99 article to write your first cucumber script: http://www.guru99.com/your-first-cucumber-script.html
We have chosen to use rails to build a small project of ours. This is a really small project and will likely take six man-months or less. All people working on the project are new to Rails and have limited amount of experience in web coding.
Our software is supposed to give users an easy-to-use interface to browse vast quantities of measurement data and visualization. Users identify themselves using a user account which limits which data they can see.
What sort of automated tests should we do and are there any freely available tutorials that would help us in this?
Consider the three "legs" of the MVC (model-view-controller) design pattern on which Rails is based.
Views
These should be largely devoid of business logic: code should be concerned with display of data and manipulation of the UI only.
Controllers
Minimal logic (conventional wisdom is to work with "thin controllers"). Testing (in the 'test/functional' directory) should be straightforward and - hopefully - mostly concerned with navigation and response content verification. Start with the idea of keeping these as simple as possible for as long as possible, so you'll be ready for the more complex testing topics when they're needed.
Models
This is where the business/domain logic lives. Keeping it in models makes it easier to test, which is good because you should be writing most of your tests against the models, particularly in the earliest period of development. Using tests to define behaviour before it's implemented has the added benefit of steering your code towards a cleaner, decoupled design, so try to do that as much as possible.
It's probably worth looking at Noel Rappin's Rails Prescriptions - there's a book and a (free) introductory PDF that covers Rails-specific test issues in some detail.
For all things rails, there are railscasts. Here's a a good one on testing with rspec: Link! (browse around to find more good stuff), and I could not recommend autotest more highly. After that, there is a lot of things you can do, depending on the test you want to write. (selenium, fixtures)
Unit testing is great and all but I think it's worth at least checking out blackbox testing
You might also want to get the book Agile Web Development with Rails. There is a chapter on using the rails testing system.
For higher level tests, you can look at Watir or Fitnesse or Selenium.
Thoughtbot's Shoulda is a very easy to use and intuitive testing framework, with natual language options and not much "magic" that has to be learned through tutorials and api reading.
Dave Thomas, one of the authors of the fantastic Rails book Agile Web Development with Rails offers a good, quick overview of Shoulda.
Everyone is talking about TDD (BDD) in Rails (and not just Rails) development world today. It's easy to find plenty of good general information about it, there are quite a few tools you can use for this purpose and there are many (good) examples of how to use them.
Now, I'm already on the train. I like the idea (never did TDD before) and I decided to go for Shoulda (because it seems to me quite easy to understand). I read plenty of examples and have done some first tests. My problem is this: I'm just not sure if I'm doing it right. As I said, there are many tiny examples all over the net, but I haven't found any comprehensive guide covering overall workflow of TDD with Shoulda.
Here are my questions:
What is your way of practising TDD with Shoulda? (What is your usual workflow throughout one iteration?)
What other tools do you use (except of Shoulda itself)?
Any other tips?
I'm using RSpec instead of shoulda, (although I believe that shoulda can be used with RSpec) and the biggest improvement to my workflow has come from using Autotest and then RSpactor.
These tools automatically monitor your source tree for changes and execute the relevant tests if update either the test or implementation file. A pretty small change to the testing practice but the immediate feed back has increased my discipline in writing tests for every piece of functionality.
+1 for Autotest.
If you have a large test suite and only want to run the test you are working on (as opposed to the whole test suite) check out this monkey patch for Autotest.
As for other tools you should check out Factory Girl as a fixtures replacement.
Most of what I know about using Shoulda came by reading others test code. Check out some of Thoughtbot's projects on github, such as Clearance and Pacecar.
I totally agree that there is a significant gap in the rails BDD documentaion. Lots of little examples but no big ones giving an overall picture of how to do it. Even the books that have chapters on testing are guilt of this. The only full examples I have seen are peepcode's three part screencast on rspec and a video on confreaks about flex mock.
I'd love to hear about other good resources on BDD that go beyond minor examples of syntax and I'd really like see a book on the topic.