Hello everyone,
I have just started learning MeteorJS and I’m having some difficulties in a few points,
In my project I’m using Meteor with:
*React
*Velocity & Jasmine for unit and integration tests
and now I’m trying to write my first acceptance test,
after a few research I found some articals talking about Selenium-Nightwatch and I’m willing to try it and I want to know if I’m on the right track ? Is there any thing better for acceptance test than Selenium-Nightwatch ?
Try https://github.com/xolvio/chimp 
It will be the acceptance testing framework of choice in the Meteor Guide
Disclaimer: I am one of the authors
Thank you very much @sam ,
I have followed the link for the chimp acceptance test, and every thing seems to be working.
But I have a little problem,
I’m using React to render my components , and I have noticed that some tests fail because the element is not rendered yet, is there any way to wait for UI element to show up?
Sure, try http://webdriver.io/api/utility/waitForVisible.html
Chimp uses Webdriver.io under the hood
Is there any good way to have cucumber feature files and step/speck files next to the source code inside a Meteor 1.3 project?
The imports/ structure is liberating - I don’t want to have test files living outside focus for juniors to ignore… again
I have translated the large app file convention structure to the official todos example. If you have the time, take a quick look and tell me what you would do for using chimp
I would love to have prominent feature files / acceptance tests to stress it for ticket completions.
Thank you very much @sam
It worked after some modifications,
according to the documentation in the link you mentioned, waitForVisible can be used like this:
client.waitForVisible(selector[,ms][,reverse]).then(callback);
but I don’t know why it worked for me like this:
browser.waitForVisible(selector, [,ms][,reverse]);
the rest of the callback code ...It is mostly because of this piece of magic:
You can read about it a bit more here:
but, basically, you don’t use chaining ( .then() ) , or callbacks
It feels just like coding in Meteor.
You can do it this way:
chimp path=./path/to/features -r=./path/to/some/stepdefs -r=./path/to/more/stepdefs
I guess it would be nice to add a glob pattern for stepdefs in Chimp so it auto adds all the directories for you as -r flags.
From a BDD purist point of view, I would argue the features and their steps should live outside. Unlike unit tests, features span across multiple components. I’ll be writing more about this soon as it’s a common testing anti-pattern that I see.
HTH
@sam thats a very good point and I completely agree.
But in this particular app structure, you follow a “feature pattern” within the imports/_screens/ directory. A screen can be seen as a “mini” app as a composition of different components to provide “access” to a feature. The feature file for “that mini app” therefore be within that directory.
As this is pretty abstract, here an illustration.
App
├── ...
├── imports/
│ ├── #components/...
│ ├── _screens/ <---------------+ Directory structure
│ │ ├── _shared/ follow routes. Routes
│ │ │ ├── _auth.jsx follow features.
│ │ │ ├── _auth.less
│ │ │ ├── _notFound.jsx
│ │ │ └── _notFound.less
│ │ ├── join/
│ │ │ └── Join.jsx
│ │ ├── lists/ +-----+ Feature Lists (Specific)
│ │ │ ├── ListsContainer.jsx |
│ │ │ ├── _Header.jsx | lists are a Feature
│ │ │ ├── _Header.less | of the App and are
│ │ │ ├── _Lists.jsx | made available under
│ │ │ ├── _Lists.less | the app.com/lists route.
│ │ │ ├── _TodoItem.jsx |
│ │ │ └── _TodoItem.less | Acceptance Test tha
│ │ ├── signin/ +-----+ lists do work as expected
│ │ │ └── SignIn.jsx
│ │ ├── _App.jsx +-----+ Feature App (Global)
│ │ ├── _App.less |
│ │ ├── _ListList.jsx | feature of using
│ │ ├── _ListList.less | routes for navigation
│ │ ├── _Menu.jsx | welcome messages,
│ │ ├── _Menu.less | connectivity status
│ │ ├── AppContainer.jsx | etc.
│ │ └── routes.jsx +-----+
│ ├── api/...
│ ├── lib/...
│ ├── server/...
│ ├── stylesheets/...
│ ├── client.entry.jsx
│ ├── server.entry.js
│ └── style.entry.less
├── ...
Imagine you want to acceptance test the user story to be able to manage lists. That feature lives with the screen - placing the feature files there - having the benefit to immediately see when you are short on tests of a particular feature.
Right now I am just thinking how to aggregate all the files again for chimp. Could chimp digest a “feature.entry.js” that requires / imports all the files from the screens sub-folders?
I have to admit, I have not yet played around much with chimp. But I certainly value your feedback.
At the domain level, the todo’s feature does this:
Feature: Manage my Todo list
As a highly organized person
I want to add and remove items to my list
So that I can manage my daily tasks
Scenario: Add items to the list
Given the todo items list contains:
| do this |
| do that |
When I add a todo item called "do nothing"
Then the list contains:
| do this |
| do that |
| do nothing |
Scenario: Remove items from the list
Given the todo items list contains:
| do this |
| do that |
When I add a remove the item called "do that"
Then the list contains:
| do this |
When described from the point of view of the actor and the intended benefit, you can see that the scenarios become less about the components that fulfill the feature and more about the value to the user.
Value testing (features) is different to component testing. Components are best tested using unit/integration tests. Features that span across components need to a) be specified correctly from the point of view of the user that consumes the value and b) be defined completely agnostic to the implementation
So I would argue that in your example, lists are a data structure component and not a feature. I would also argue that a navigation bar is a component but not a feature. These can be tested either in isolation, or in context using an integration test. I would have a mocha/jasmine test that says:
describe('The navigation bar', function() {
describe('list navigator', function() {
it('should route the user to the selected list', function() {
// setup: create some lists
// execute: invoke the list navigator (SUT)
// verify: check the router was called (or that the URL changed in an integration test)
};
};
})
No need. Just put all the files you want in a directory (or set of directories) and pass it the -r flag for each directory that contains step files.
Hope that helps
@sam don’t take the _screens/ folder to literally. Its just the place where for each feature, i.e. having a list or beeing able to sign in the necessary files are imported from all over the place of the app. Such as ui components and apis to provide you the lists feature. A little bit like micro services. Of course, unit tests would live directly with the unit they are testing.
But given your example above, what stands in the way to put the feature file and step tests into the _screens/lists/ folder? Than I want to add a dashboard too because “as a data driven person I want to see burn charts of my accomplished tasks”
and all that would come together in the _screens/dashboard/ folder. Having a dashboard.feature file with step definitions sorted with it.
You’ll see I try to shift a little bit the paradigm of what the _screens directory is. That is the reason why its not called “views” because it’s not a part of the MVC - its the experience of the end user coming together.
Totally get it and think it’s a great way to develop so I like where you’re heading. I tried this approach previously and it worked.
your fingers and the keyboard
so I’ll just wire up chimp to fish the files out of the folders. Great. Some time I’d love to talk face2face with you. You do have some great work and a great mindset!
I’ll post a work in progress article about Meteors 1.3 App Structure & A/B/Multivariate testing later in the forums for feedback. This was one part of the puzzle.
Thanks for the kind words and sure, I’m always down to talk. Let me know and looking forward to the article.