Should I just write some tests? If so, should they be behavior-driven development ( BDD) based tests or test-driven development ( TDD) based tests? Maybe I should take an entirely different approach?
Every time I start working on a new project, I reevaluate what my practices should be. Since I know I'll need a number of things — fake data, a website, and to display that fake data on the website — I could easily write that up. But my goal here is to explain some practices that developers …
Next on our plate was to choose a test runner. None of us on our team are fans of BDD style testing; we wanted a very lean test runner and library with simple assertions and standards-compliant machine-readable output. This led us to use tape as our test framework, and we have been quite pleased with it. Our tests run in Jenkins , and the TAP Jenkins plugin reads our test output perfectly.
This setup worked great for us in the beginning, but we also needed …
…works as expected. Because we wanted to use Mocha with Chai BDD matchers instead of QUnit , the initial test setup was a bit complex but after using Konacha with a Mocha adapter , it was smooth sailing. The extra setup time for over was definitely worth it. The syntax has a much more readable format. describe 'AggregateStatsController', -> describe 'summed properties', -> beforeEach -> stats …
Jasmine's syntax should be very familiar to anyone who does RSpec BDD work, and the work we've done in our spec helper really cleans up the beforeEach setup that's required in each individual controller spec. These particular tests make heavy use of ngMock, which you won't always need to use, and the calls to flush() are required to fulfill pending requests, preserving the async nature of the backend but allowing the tests to execute synchronously.
BDD is powerful stuff, and it's much more powerful when your product owner understands the benefits .
We love having product owners at BDD Kickstart . The first day is all about the collaborative aspects of BDD where we learn how to break down and describe requirements using examples. We find that product owners really enjoy it.
That's why we're announcing a special promotion for our next public course in. Use the discount code " BYPO" …
I think balance is important. Whenever I teach people about BDD or automated testing , we make a list of the costs and benefits of test automation.
The lists typically look something like this:
thorough analysis of a requirement
confidence to refactor
quick feedback about defects
living / trustworthy documentation
frees up manual testers for more interesting exploratory testing
time spent leaning how to write a test
time spent writing the test
Naming things is hard. Witness things that developers have named and then struggle to explain because words and people are weird:
TDD sounds like it's about testing, but it's really a design technique.
BDD sounds like it's about what code does, but it's really a communication discipline.
Outside-in development sounds like a way to discover the design of software, but it's really a technique for building software using a fractal todo list.
…pipeline, including Sprockets & Sass; behavior-driven development ( BDD) with Capybara & Rspec; better automated testing with Guard & Spork; roll your own authentication with has_secure_password; and an introduction to Gherkin & Cucumber. These focused video lessons help you learn crucial new skills fast— and put them to work immediately! Watch top Rails developer Michael Hartl guide you through building a complete application using today's best practices …
This is the single most powerful behavioural shift I have seen in teams adopting BDD. Simply by getting the business users, the analysts, the testers and the developers to adopt this vocabulary of "given/when/then", they discover that a world of ambiguity falls away.
§ Top 10 Weird APIs , serving your facts, making fake calls, and …
I made a presentation on Refactoring & BDD atback on 10/09/2012. I put my slides and notes from the presentation up on Deck.
Some quick takeaways ...
The less your problem is understood, the more complicated your solution is likely to be. This is one of the reasons why we refactor code - we increase our understanding of the problem domain and increase our abilities to apply solutions to the domain as time goes by.