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

Already on GitHub? Sign in to your account

This is much jasmine hell as I could raise in an hour #1

Open
wants to merge 7 commits into
from

Conversation

Projects
None yet
2 participants

searls commented May 17, 2012

I just tried to hack up as much of this as I could without changing any production source.

searls added some commits May 17, 2012

@searls searls switched from evergreen to jasmine-headless-webkit 9de8db2
@searls searls Converted specs to CoffeeScript 6b5c6c5
@searls searls adds jasmine-jquery, uses some of those matchers ae19090
@searls searls convert DSL-style to that of jasmine-given 58efb86
@searls searls introduced jasmine-fixture for DOM fixtures
  (I'm recognizing how hilariously unnecessary
     this all is so far, given the test coverage)
a930fe1
@searls searls these collection guards seem unnecessary 2b4ded1
@searls searls I actually prefer to test bindings and public API
  separately, so I've reworked the tests to demo
  that a bit. 

This change is 50% style and (IMO) 50% beneficial.
  The benefits are primarily that it tends to make
  unit isolation a tad easier to pull off, and in 
  the long run I've found specs that focus on 
  tackling named methods easier to maintain. I say
  maintenance is easier b/c the spec tells me the 
  public API very clearly (when I need to change
  a method I know where to go), and when a second
  event calls the same method, I don't have to hide
  behind any shenanigans like "shared example groups"
  to DRY things up.*

*But really I do love shared example groups when
  they make sense
2cbe93c

Yeah, there were needed before I mocked out fetch

Owner

bkeepers commented May 19, 2012

Nicely done.

I'm not actually sold on jasmine-given. I think it's a really interesting idea, but I don't love it. It doesn't feel to me like it adds clarity. Want to convince me?

searls commented May 19, 2012

The benefits of the *-given style are nuanced, and they become clearer
if you just give it a try (I was actually turned off to them until Jim
Weirich encouraged me to try rspec-given on a real project).

So, with the caveat that "you just have to try it", I do like these
aspects a lot:

  • No it strings - the vast majority of example descriptions I write
    are obvious if you read the expectation. The non-obvious expectations
    should be made to be obvious.
  • Every arrange/act/assert action you take is pressured into being
    expressed in one line, and as a result: clearly. In multi-line
    beforeEach and it blocks, the test phases are often ambiguous (or
    out-of-order)
  • The act of refactoring spec code is much easier, because each line
    can easily be pulled up or pushed down to a different level of
    nesting (great for DRYing specs up)
  • Most of my tests boil down to easy boolean assertions, so I like
    that returning false from a Then will trip a failure. (meaning I don't write
    expect() so much)

As a bonus, after converting a very large project to jasmine-given I
was happy to find that the ratio of spec-to-production lines dropped
from 4:1 to around 2.5:1. The increased information density just made
it easier to read and less intimidating to others.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment