andrewsardone + bdd   13

Steve Tooke - The Cucumber Test Trap
A good read on the big ball of mud situation you can get *within your acceptance tests*. The conclusion is mostly sound:
Writing scenarios with your customers will help you to understand what your application needs to do, and automating those scenarios with cucumber will help you to know when the application meets those needs. Just don’t fall into the trap of thinking you can use cucumber to test the app completely at the expense of unit tests or Lots of Scenarios and a Big Ball of Mud will be your reward.

I do take issue with the more extreme point, namely, [that integration tests are a scam][sc]. The ideal outside-in development cycle has you first *communicate* the larger behavior of the app within a scenario. This gives you a place to codify what something does, but it also gives you a way to verify this behavior. With this test existing outside of any unit-level of code, it's verifyiable independent of implementation design.

In my experience, this has a big advantage: **you can [build one to throw away][ta], but still verify behavior**. It sounds like bullshit, but starting from the outside gives us some amount of guard rails to make sure there's baseline functionality. One can define the scenario, and then quickly implement it with no thought about the design – you can see what you're up against. Once that's passing, go ahead and tear everything down and start over. Now, focus on your design, test first at the unit level, and see what you're now up against.

It's not the only way to work, or the method that applies everytime, but I find it pretty valuable.

bdd  cucumber  testing  goos  via:mikelinington 
april 2014 by andrewsardone
Quote: Cucumber is not a tool for Automated Testing
Cucumber is not a tool for Automated Testing, it's a tool for Collaborative, Executable Specifications
cucumber  testing  bdd 
december 2013 by andrewsardone
Calling Steps from Step Definitions · cucumber/cucumber Wiki
I didn't realize you could call other steps *within* a single Cucumber step definition

Given /^(.*) is logged in$/ do |name|
steps %Q{
Given the user #{name} exists
Given I log in as #{name}
cucumber  bdd  testing 
december 2013 by andrewsardone
Magic Tricks of Testing // Speaker Deck
A good run through of what one should be unit testing, making a distinction between command and query methods in the context of who's sending the message (incoming from outside, message to self, or outgoing message to collaborator).

The bookmark links to an easy grid to help keep these things straight.
tdd  bdd  testing 
april 2013 by andrewsardone
sgleadow/xcodetest · GitHub
Run Xcode project unit tests, including 'application' (not just 'logic') tests. It looks like it requires creating an entire scheme for your tests.
ios  tdd  bdd  cli 
january 2013 by andrewsardone
A Matcher Framework for Objective-C/Cocoa

I'm not sure if this should be used in conjunction with Kiwi or instead of Kiwi combined with some other tool (specta, cedar, OCUnit, etc.).

A simple example spec-ing a CGRectDivide macro:
tdd  bdd  ios  objective-c 
october 2012 by andrewsardone
A light-weight TDD / BDD framework for Objective-C & Cocoa.

- No built-in mocking – should use OCMock/LRMocky
- Can use OCUnit assertions/matchers, but should probably be combined with something like Expecta or OCHamcrest
ios  bdd  tdd  objective-c 
october 2012 by andrewsardone
Better Specs
Better Specs tries to collect a series of best practices around RSpec and its fleet of tools. Every best practice is linked to a GitHub issue to facilitate discussion.
rspec  ruby  bdd  testing 
october 2012 by andrewsardone
Myron Marston » RSpec's New Expectation Syntax
foo.should == bar
# vs.
expect(foo).to eq(bar)
rspec  syntax  ruby  bdd  tdd 
october 2012 by andrewsardone

Copy this bookmark: