Re: Acceptance testing
Michael Cohen
Regarding how you access sub-items in a list view using Lebowski, yes,
you need to expand the parent node like you have done. This is not a
limitation of Lebowski as it's how SproutCore's tree item observer
works (SC.TreeItemObserver). Let's say you have the following object
structure that you pass to a tree controller:
rootItem
-- Item1
-- Item1.1
-- Item1.2
-- Item2
-- Item2.1
-- Item2.2
And you link the tree controller to the list view like so:
list: ListView.design({
content: 'MyApp.someTreeController.arrangedObjects'
})
Assuming we are not showing the root item in the list view, but the
root's children instead, the tree item observer is set up such that it
will only return items based on what has been expanded and collapsed.
Therefore if, by default, item1 and item2 are not expanded, then when
you access the content's first item (index 0) from the list it will be
item1 and the second item (index 1) will be item2. Now if we expand
item1 and try to access the second item again we will get back
item1.1. To access item2 when have to get the fourth item (index 3).
This all works by delegation when you try to expand and collapse item
views that contain child items. The backing tree item observer gets
the collapse and expand calls to then update the structure returned
ultimately by the tree controller's arrangedObjects property.
With that all being said, it would interesting to add a capability to
lebowski where you can access the tree controller's backing content
object to search through the object hierarchy. Based on the found item
and the path to that item from the root item, auto- expanding and
collapsing could occur by lebowski, which would remove more of the
explicit approach you are currently taking to expand all the items in
the list. I'll have to ponder that idea a bit more :-).
Regarding your lebowski setup, you do not need to use the following
line when starting your app:
app['isLoaded'] === true
That is an old line that I forgot to remove until just recently. As
for the isPaneAttached check, this is independent of any back-end,
such as Rails. isPaneAttached is a property on the SC.Pane that
indicates that the pane has been fully rendered and attached its
backing DOM element (read: layer) to the web page's DOM body element.
Using isPaneAttached is a good check since it typically means your app
is ready to use; however, there may be more checks you have to do
depending on how you startup your particular application. Also be
careful when you do checks within the function passed to the start
method. The evaluation returned by the function will always be the
last line executed. So if you have the following:
App.start do |app|
app['mainPage.mainPane.isPaneAttached'] == true
app['isLoaded'] == true
end
Then if isLoaded is false but isPaneAttached is true, the result
returned will be false because isLoaded is the last check done. That
is a characteristic of Ruby, not Lebowski.
Finally, if you want to close the browser after your tests have
complete, you can call the main app object's end method:
app.end
Hope all that helps you out.
Mike
On Feb 9, 11:09 am, Sébastien Nicouleaud
<sebastien.nicoule...@gmail.com> wrote:
> @Thomas: Thank you for sharing your setup.
>
> My features/support/env.rb is very similar to yours, except I used an ugly
> hack to be sure my test won't get run before the tree is populated:
>
> App.start do |app|
> sleep 5
> app['mainPage.mainPane.isPaneAttached'] == true
> # app['isLoaded'] == true
> end
>
> None of the isPaneAttached/isLoaded condition seems to work in my case.
> May have something to do with my rails backend ?
>
> I also added the following lines, because I was getting mad of all the
> remaining open firefox windows:
>
> After do
> `killall firefox-bin`
> end
>
> Not really a good idea if you're using firefox as your main browser...
>
> Le 9 février 2011 16:46, Sébastien Nicouleaud <
> sebastien.nicoule...@gmail.com> a écrit :
>
> > Thank you guys, for your answers.
>
> > Actually, I had a hard time at retrieving the content of a tree view using
> > cucumber+lebowski.
> > I tried to use both the #item_views and #content methods on the tree proxy,
> > but both only give me the root items.
> > I can get the whole content by expanding every node of the tree, but there
> > should be a better way to do this...
>
> > Here is my current step definition:
> >https://gist.github.com/818679
>
> > Any thought ?
>
> > Seb
>
> > 2011/2/9 Thomas Reynolds <tdre...@gmail.com>
>
> > I'm using Cucumber on Lebowski using this cucumber env.rb:
> >>https://gist.github.com/740817
>
> >> -Thomas
>
> >> On Tuesday, February 8, 2011 at 10:51 PM, Scott Smith wrote:
>
> >> Wow, great discussion. So is anyone using Cucumber on top of Lebowski?
>
> >> Scott - OldFartDeveloper
>
> >> On Tue, Feb 8, 2011 at 9:24 AM, Michael Cohen <
> >> michael.lee.co...@gmail.com> wrote:
>
> >> Hi Greg,
>
> >> Thanks for the comments. It appears that your take on Lebowski is more
> >> from a level of abstraction and how you would like write your
> >> acceptance tests.
>
> >> First, I agree that it is much more desirable to build acceptance
> >> tests that are at a level of abstraction, say, at a generic use case
> >> level. Writing such tests definitely floats above the individual
> >> views, controllers and model objects that make up a SproutCore
> >> application and make it much saner to communicate concepts with
> >> individuals beyond developers and QA. This is why it definitely makes
> >> sense to use Cucumber to apply that level of abstraction and use
> >> Lebowski for the lower-level mechanics of actually interacting with
> >> your SproutCore app.
>
> >> Now, regarding Lebowski itself and the DOM, writing your acceptance
> >> tests that access the DOM directly is something that can certainly be
> >> done, but there are a couple of problems. First, working with DOM
> >> directly instead of going through SproutCore itself is incredibly
> >> brittle, especially if you're trying to access DOM elements
> >> representing a view's layer. Second, handling user events (mouse
> >> events, keyboard events, touch events) is tricky when, say, using raw
> >> Selenium or what have you. There are a lot of subtleties in how you
> >> get various use actions to properly work, like single click, double
> >> click, any kind of keyboard event, drag and drop, etc. Third, by
> >> avoiding any kind of proxy that represents a view, you have no
> >> mechanism to abstract the low-level mechanics of how to work with
> >> them, which leaves you exposed to difficult to maintain code when you
> >> write your acceptance tests.
>
> >> At the end of the day, Lebowski really needs to be seen as a solid
> >> middle-tier when writing acceptance tests. It sits above working with
> >> low-level DOM and JavaScript, and sits below high-level ways of
> >> writing acceptance tests that represent general use cases. By skipping
> >> Lebowski as a middle-tier and writing your higher level acceptance
> >> tests to work directly with the low-level DOM mechanics, you will be
> >> setting yourself up for a lot more work with respect to getting your
> >> tests to work and maintaining your tests.
>
> >> If you're writing an web app that uses SproutCore, then having a
> >> framework that lets your talk at that level of specificity will help
> >> improve where problem exists if your application's structure or
> >> behavior changes. And while it helps facilitate communication between
> >> developers and QA, it in general helps developers maintain sanity. You
> >> could imagine a new dev coming onto a SC project and having to
> >> decipher between scripts that focus at the raw DOM versus scripts that
> >> focus at SC's MVC level. That all being said, I wouldn't use Lebowski
> >> as something you can show to your product and project managers, sales
> >> reps, or even end users since that's clearly not the audience Lebowski
> >> is intended for.
>
> >> Again, I very much appreciate your comments. Having these
> >> conversations are important for people who are using Lebowksi or maybe
> >> thinking about using it.
>
> >> Cheers,
>
> >> Mike
>
> >> On Feb 8, 11:23 am, Gregory Moeck <gmo...@gmail.com> wrote:
> >> > Mike,
>
> >> > I think this is on topic, but if not I'd be glad to e-mail you and talk
> >> > about it as well.
>
> >> > First off, I think that Lebowski is a really interesting project, and I
> >> > think that it's great that your making things easier for testing
> >> purposes
> >> > within Sproutcore. I do not in anyway want to discourage that, as I
> >> think
> >> > that testing is not one of our communities strengths. The things that I
> >> > didn't like about the framework have more to do with the testing
> >> philosophy,
> >> > and the way that I do testing than Lebowski's ease of use. I had no
> >> problem
> >> > getting it running, or anything like that.
>
> >> > I'll mention the two biggest philosophical differences I have with the
> >> > framework:
>
> >> > 1. Lebowski is tied directly to the Sproutcore architecture, which means
> >> > specifying the tests in a Sproutcore type way
>
> >> > In your selenium meetup talk you said the following: "I want to be able
> >> to
> >> > say to the QA people, 'What went wrong?', and have them say, 'This
> >> *view*
> >> > didn't work'...'from this particular *property path*'...".
> >> Philosophically
> >> > this isn't what I want to do with my acceptance/integration tests. I
> >> want to
> >> > specify something more akin to "I should see this on the screen", and
> >> "When
> >> > I do this action, then I should see this". I want my
> >> acceptance/integration
> >> > tests to specify the interaction with my application from a user's
> >> > perspective, in order to maintain and assure the values which the user
> >> > requires. My users shouldn't be thinking in terms of the MVC, or the
> >> > property path, and so I don't want my acceptance/integration tests to be
> >> > specified in that language. This sort of detail is what I use my unit
> >> tests
> >> > for, specifying how the application accomplishes those domain specific
> >> > tasks. Theoretically this problem could be eliminated by using a tool
> >> like
> >> > Cucumber to specify the domain language level stuff, and Lebowski to
> >> specify
> >> > the connection with the application, but I think (for now at least) I
> >> would
> >> > rather interact with the DOM, and just have a layer that maps the way
> >> the
> >> > user thinks into what that looks like in the DOM for Sproutcore (for
> >> > example, I want to say click in my tests, but map that to a
> >> > mouseup/mousedown).
>
> >> > 2. Lebowski is tied directly to the Sproutcore View architecture, which
> >> > means that I have to have specify the implementation of my views in my
> >> > acceptance/integration tests
>
> >> > Personally, I use my acceptance/integration tests not only to verify
> >> > behavior of already written software, but also to help drive the
> >> > implementation of the software that I'm currently writing. In doing
> >> that, I
> >> > am a proponent of emergent design. So for example, I start off by
> >> writing a
> >> > failing acceptance/integration level test, then write a failing unit
> >> tests,
> >> > make that unit test pass, write a failing unit test, make that unit test
> >> > pass...etc until that acceptance/integration test passes. What this
> >> means
> >> > for me is that I don't want to have to think or specify in terms of this
> >> > certain view class, or this certain path within the page if I don't have
> >> to.
> >> > I want to let those objects, and paths emerge naturally over the course
> >> of
> >> > growing the system. Having to stop and write a proxy object for an
> >> object
> >> > that doesn't yet exist in the system for me just doesn't really make
> >> sense.
>
> >> > Overall, I think it's great that Lebowski has improved your interaction
> >> with
> >> > your QA people, and made it so that you can verify that your app is
> >> still
> >> > working as intended. If someone were looking to do just that, I would
> >> likely
> >> > recommend using Lebowski. But I don't even interact with QA people, and
> >> I
> >> > use my tests to do more than just verify the behavior and the condition
> >> of
> >> > my app. As such, I didn't find it to really work with my approach to
> >> BDD.
>
> >> > Hope that helps, and clarifies.
>
> >> > Greg
>
> >> > On Tue, Feb 8, 2011 at 7:19 AM, Michael Cohen
> >> > <michael.lee.co...@gmail.com>wrote:
>
> >> > > @sebn: The acceptance testing we are using is all done with Lebowski.
> >> > > Lebowski at its core is independent of any testing framework like
> >> > > RSpec and such, so you can use it with Cucumber. That being said, I
> >> > > would like to update Lebowski so that there are extensions for
> >> > > Cucumber just like I added extensions for RSpec. If you'd like to know
> >> > > more, please feel free to ask.
>
> >> > > @Gregory: Would you be able to expand on what you didn't like about
> >> > > the proxy approach to handling views. I'd be interested to know as I'm
> >> > > always looking for ways to improve Lebowski and make it easier to
> >> > > use :-).
>
> >> > > Mike
>
> >> > > On Feb 8, 3:52 am, sebn <sebastien.nicoule...@gmail.com> wrote:
> >> > > > Hello guys,
>
> >> > > > Just a quick question:
> >> > > > I'd like to know which tools people are using (if any) for
> >> sproutcore
> >> > > > acceptance testing ?
>
> ...
>
> read more »