

Sleipnir: BDD-style framework for Swift - AlexDenisov
https://github.com/railsware/sleipnir

======
zackmorris
For anyone curious: Behavior-Driven Development (BDD) is a business logic
alternative to Test-Driven Development (TDD). It uses more of a conversational
tone to spell out tests, so you write what you would like the app to do rather
than sitting there scratching your head trying to figure out which tests to
write. So it places emphasis on the "what" you want the program to do, and
fill in the "how" behind the scenes. You can actually write all of your BDD
gherkin and test fly your app with known inputs and outputs and then add the
logic for arbitrary input and output later. Here is an example implementation
for PHP:

[http://codeception.com](http://codeception.com)

~~~
rubiquity
Oh, boy. As usual anyone trying to define the difference between BDD and TDD
gets it wrong. The difference between TDD and BDD isn't the tone in which you
describe your test examples. The difference lies in the depth of the layer you
start developing a system (or subsystem) at. Some refer to this as Outside-In
versus Inside-Out. BDD and TDD have nothing to do with DSLs or the tone in
which you describe your test examples.

As an example, I practice BDD but I use MiniTest, a "TDD" testing library.

~~~
parasubvert
BDD's difference in comparison to TDD absolutely has to do with tone - more
likely philosophy of how one programs. It's about whether you're more
comfortable verifying behavior or state. Mockist testing and BDD is the former
, Classic TDD is the latter.

TDD doesn't care how you write the test since it's about verifying states.
Kent mostly used it for inside-out testing and never uses mocks, but sometimes
plays with middle-out or outside-in interactions using programmer tests, fake
objects, and stubs.

Only BDD was about specifying the test as a behavioural description in a DSL,
and is always outside-in. It's pretty clear cut.

~~~
rubiquity
It seems you're misinformed as well.

[http://c2.com/cgi/wiki?BehaviourDrivenDevelopment](http://c2.com/cgi/wiki?BehaviourDrivenDevelopment)

Again, nothing to do with silly syntax. It's about acceptance testing.

~~~
parasubvert
It seems you're not reading what I (or anyone else) wrote.

I never mentioned syntax. I mentioned a DSL. Using a DSL is about much more
than syntax, it is about expressing verifiable behavior tests in a ubiquitous
language. I said nothing about any specific syntax of external or internal
DSL, heck people contort FitNesse to fit BDD for whatever reason.

I have been on Ward's wiki since 1998, this isn't exactly _new_. It's also not
for everyone.

~~~
rubiquity
Sorry, by syntax I meant DSL.

So by your logic, a language that doesn't have good ability to create DSLs
can't do BDD?

------
The_Pherocity
I wouldn't call this a BDD framework yet. It's speckled with both standard
assertions and semantic assertions, and an "It" function that simply takes a
block and a string. I can replicate this with using underscores in my test
function names and avoid the complexity. Not trying to be a jerk, but what we
should be driving for is something closer to:

    
    
        func Describe("The system I want to Test"){
            When("I click the red button")
            Then("I should see the light turn on")
            And("I should see 4 lights")
        }
    
        func Step("I click the red button"){
           buttons["red"].click
        }
    
        func Step("I should see the light turn on"){
           lights.on.should().be_true
        }
    
        func Step("I should see (\d+) lights"){
            lights.count.should().be(4)
        }

~~~
21echoes
it depends on what you consider "BDD". The linked library is nearly identical
to Cedar (
[https://github.com/pivotal/cedar](https://github.com/pivotal/cedar) ), which
is, in turn, nearly identical to rspec (
[http://rspec.info/](http://rspec.info/) ). Both of these libraries are very
much considered BDD. You seem to be advocating something closer to
cucumber/gherkin?

~~~
The_Pherocity
Maybe somewhere in the middle, but fair point. I have my bias for the style
change, though that was a distraction from my point. It's premature, and in
it's current form, doesn't add much value.

------
dmurdoch
Typo in the page title of "BDD-style framerwork for swift
[http://railsware.com/blog/2014/07/04/bdd-style-testing-in-
sw...](http://railsware.com/blog/2014/07/04/bdd-style-testing-in-swift-with-
sleipnir/")

Should be "BDD-style framework for swift
[http://railsware.com/blog/2014/07/04/bdd-style-testing-in-
sw...](http://railsware.com/blog/2014/07/04/bdd-style-testing-in-swift-with-
sleipnir/")

~~~
AlexDenisov
Thank you! Fixed.

------
tsenkov
It's so nice to see how new ecosystems emerge. Looking forward to many more
frameworks and tools for Swift.

------
woah
I just want to say: Awesome logo.

~~~
MaxGabriel
Agreed. Did you do the logo yourself?

~~~
AlexDenisov
Thank you, guys. Our designer did it
([https://dribbble.com/shagov](https://dribbble.com/shagov))

