Hi! Thanks for your post ideas!

How Cucumber and Rspec tests are interwoven is explained in RSpec book (they show full BDD cycle starting with Cucumber test, then using this test for discovery of following, more low-level RSpec tests) but you’re right that this is not fully clear (I’ve also had some problems with grasping these ideas during the first read). RSpec book also omits JavaScript in this process. I think I may try to tackle this problem in one of my future posts.

As for the second idea, I’ve planned a similar post about DRY tests (like this one) but for Cucumber (maybe even as my next post). I think that indeed it may be a good idea to include also a discussion about instance variables and maintaining state in this post.

(1) I find the BDD “jump” from Cucumber to RSpec (or Test::Unit) difficult conceptually. I think your examples may be clearer that in the RSpec book! Anyway, I think that’s a great topic that is hard for people to get right.

(2) I have been noticing that there is a code smell around putting instance variables in Cucumber steps. Maybe it’s OK for a top-level “Given” to instantiate an object under testing. Anyway, it’s interesting to me that in tests using web_steps the “state” is maintained in the browser that is being exercised (so no state in an object is set up with “new”). I wonder if there is any advice on this topic? The RSpec book does have instance variables in steps, but it never really discusses them (indeed, the actual “steps” code examples aren’t even finished in that book – there are just minimalist bits to illustrate issues).

Think also if it really must be verified in such a complex fashion. When you think deeper about it, you can identify two main parts of your code:
1. opening new window
2. manipulating DOM in a window

Maybe you could split the code in an OO fashion into two parts (window opener and DOM manipulator) that could be tested separately, in isolation?

First test would verify if your code can properly open new window and obtain a handle to some DOM element in this window (but the content of the element would be irrelevant at this point, so you wouldn’t need fixtures).

Second test would verify if DOM is manipulated properly, assuming that new window is already opened and a handle to DOM element you want to manipulate is already obtained. With these assumptions, you could test DOM manipulation only (what can be done in the same window your tests run in – and thus can use jasmine-jquery fixtures to the full extent).

Such approach (if it is possible for you) would not only make tests much simpler and easier to run, but probably also improve the design of your SUT by facilitating decoupling.

I’m thinking about following scenario:

Your JS code runs in window A. It opens window B in order to manipulate its content in some way. In order to be able to manipulate content of window B, code in window A must keep a handle to window B somewhere.

So I wonder if it couldn’t be tested like this:
1. you have a window A with your System Under Test and your Jasmine suite.
2. in one of your specs your SUT tries to open window B
3. your Jasmine code intercept this somehow (e.g. by mocking a method opening window B etc.), obtains a handle to window B, and manipulates the content of window B by injecting a HTML snippet into its DOM (loaded from fixture). In such case loadFixtures method will not work, because it expects to be run in the current window, but I think it may be possible to get fixture’s content by invoking getFixtures and then inject this content into DOM of the window B (this is the “manual hack” part I wrote of earlier)
4. Jasmine lets the rest of your SUT’s code to run (and to do something with window B DOM)
5. Jasmine again uses window B handle (stored earlier) to access window B DOM, and invokes some matchers on window B content.

You need also to remember, that opening window B will be async, so you need to use Jasmine’s async facilities in order to maintain proper open-inject-modify-verify order of your test execution.

PS: this is only a raw idea, it is by no means verified, but I think that with some experimentation there is a chance similar solution may work.

Example:

window_1 opens window_2 by clicking a link (not important to test) but then some interactions with JS happends in window_2 and the JS code finishes by making some changes on window_1 by calling sometime at the end opener.$(‘#my-selector-on-window_1′).append(‘bla bla bla’);

My problem is how to tell jasmine the relationship as window-opener between window_1 and window_2

Ideas?