Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Helper functions. Before or after the spec definition? #8

Open
mokagio opened this issue Sep 7, 2017 · 4 comments
Open

Helper functions. Before or after the spec definition? #8

mokagio opened this issue Sep 7, 2017 · 4 comments

Comments

@mokagio
Copy link
Contributor

mokagio commented Sep 7, 2017

Often we define helper functions, to DRY our specs. Should they go before or after the spec definition?

Please vote with a 👍 on the option that you prefer.

@mokagio
Copy link
Contributor Author

mokagio commented Sep 7, 2017

Before

private func makeFoo() -> Foo {
  return Foo(a: "b", c: "d")
}

final class BarSpec: QuickSpec {
  it("bars") {
    expect(Bar.bar(with: makeFoo()).to(beTrue())
  }
}

@mokagio
Copy link
Contributor Author

mokagio commented Sep 7, 2017

After

final class BarSpec: QuickSpec {
  it("bars") {
    expect(Bar.bar(with: makeFoo()).to(beTrue())
  }
}

private func makeFoo() -> Foo {
  return Foo(a: "b", c: "d")
}

@mokagio
Copy link
Contributor Author

mokagio commented Sep 7, 2017

My vote goes to after.

The reason I like it is because to a reader the most important thing is to read the spec code, and as such it should come earlier. Having all the secondary information, the helper function bodies etc, later on, allows a reader to focus on the core of the logic first, and drill down on the details only if they need.

This is inspired by the teachings of the book Clean Code.

@RodBrown1988
Copy link

RodBrown1988 commented Sep 14, 2017

I vote for after as well, for the same reasons.

The Spec itself is the test, and therefore the appropriate element for focus in the file. Additional helpers are more implementation details, which are often not relevant when you are examining and trying to understand the test.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants