Introducing the StarryNight utility

announce
21

Installation failed on win 8.1 64bit
http://www.filedropper.com/npm-debug

22

Huge documentation update posted online, including a testing manual, new API reference, and 6 tutorials.
http://starrynight.meteor.com/

Thereā€™s another 6 tutorials that are on their way (Mobile, ActiveRecord, Continuous Integration, HIPAA, Weblog, MultiActor); plus a big upgrade to the API reference section, which should all go online in another month or two; after we finalize the isomorphic Describe/It API, and get the Specifications API integrated.

3 Likes
23

Does StarryNight have an option to target webdrivers besides chrome ? For example, run the tests with FirefoxDriver ?

thanks.

24

Oh, for sure. It supports Chrome, Firefox, and Phantom pretty much out of the box. Just configure the .meteor/nightwatch.json file. Hereā€™s a rosetta-stone config file that has all of them configured:

The one caveat is that youā€™ll need to install Java for OSX and Firefox 35, as I recall. We moved away from Firefox to Chrome because a) Firefox was falling behind in itā€™s API and we had to use an older version, and B) weā€™re grooving on using Chrome as an isomorphic API between Client, Testing, and Editor (weā€™re using Atom as our IDE).

http://support.apple.com/kb/DL1572
https://ftp.mozilla.org/pub/firefox/releases/35.0/

1 Like
25

How much development is currently going on over at the starry night project? Just been trawling through the site and see that a lot of features still need to be implemented and am thinking about using it in as we build up the testing foundation of a health application that is already in production

26

Well, itā€™s certainly not dead. We use it on a daily basis for all of our QA and have three new apps going live with it this month alone. Itā€™s just been in a holding pattern as ES6 imports feature gets sorted out.

FYI, In the past two months, most of the development work has involved adding the istanbul code-coverage framework and support for the meteor test command. For the later, we need a command-line test runner, which is what spacejam is for; but it needed a driver update, which was blocking for like 3 or 4 moths. The device driver was finally delivered in Meteor 1.3.3 So weā€™re actually ready to do some more development. Except that Iā€™m tied up with MeteorCamp and a dozen other projects, of course. But thatā€™s just life, I suppose.

August will probably see code-coverage and meteor-test will go in, and Iā€™ll probably migrate the entire website over to the Clinical Meteor homepage.

Which features in particular do you feel need to still be implemented?

27

Okay wow, and yeah I look forward to seeing it move forward. Looking it over, seems like weā€™ll be able to move forward with utilizing it. I would love to see the Meteor Night Watch API finished though. It would also be nice to, as an option when running a testing framework, have the tests auto run on code save/server update for local development. Iā€™m sure I can reasonably arrange that manually however.
Iā€™d love to contribute. Hopefully Iā€™ll be able to submit a pull request this weekend with regards to some of the site content and more in the future to actually help develop the API.
Thanks for all your work!

28

The design philosophy behind StarryNight is to run tests onCodeCommit rather than onFileChanged. This has been the source of much debate, and is one of the main reason why we broke off from the velocity project and created our own utility.

Weā€™ve tried re-running tests on file change, but for the validation tests required by the FDA (i.e acceptance and end-to-end tests), it just doesnā€™t work well. Weā€™ve found a much better workflow to be to run tests at the end-of-day, at the end-of-sprint, in QA branches, and during pull-requests. Take a look at the GitHub Status API for more details.

Thereā€™s also a starrynight-helper package, which provides GUI controls from within Atom. Again, the idea being to not exactly run validation tests on every file change, but to provide tools that will let devs run tests frequently.

As for the API page, glad to know that you see the value in it. That was another major design consideration that we disagreed on. The general inspiration for that page is from the Nightwatch API page and docs.meteor.com. And while the API page never got detailed description, it does provide some basic guidance (which is hopefully better than nothing). A few notes regarding the API page:

  • Iā€™d prefer to use jsdocs to build that page rather than hand code it, which is why it isnā€™t more detailed.
  • The TinyTest API has been effectively deprecated.
  • At this point, itā€™s pretty safe to say that itā€™s been replaced by the Chai API by all modern test frameworksā€¦ Nightwatch, Gagarin, SpaceJam, Chimp and Mocha all support it. So itā€™s safe to claim Chai as an isomorphic testing API.
  • The Mocha lifecycle API is also very close to being isomorphic, since Nightwatch 0.7 added Mocha support, Gagarin is a superset of mocha, meteor-test uses mocha, as does SpaceJam.
  • However, there is some small discrepancies between before and beforeEach. One of the frameworks runs before() on each test. Gagarin maybe? I forget which one. So thereā€™s a bit of work left to be done, but itā€™s very close.
  • Any pull requests towards the Meteor API will be happily accepted. Just follow the **sessionEquals()**example.
  • The StarryNight website is likely to get incorporated into the clinical.meteorapp.com website later this year.

Also, it should be noted that StarryNight began as a collection of NPM scripts from the Meteor Cookbook. Instead of keeping recipes around, I eventually converted them into code, and put them into a meta-utility. In theory, most of the StarryNight commands could be add to the Meteor tool itself.

More interestingly, as of Meteor 1.3, Meteor now supports package.json files, which means that StarryNight commands can also be detached and run with meteor npm script. So Iā€™m currently debating whether it makes sense to do a more straight-forward integration with something like the following:

  "scripts": {
    "start": "meteor --settings settings-development.json",
    "test": "meteor test --driver-package practicalmeteor:mocha --port 5000",
    "validation": "nightwatch --config .meteor/nightwatch.json",
    "verification": "gagarin tests/gagarin/*",
    "staging": "meteor deploy staging.meteor.com --settings settings-development.json",
    "production": "meteor deploy production.meteor.com --settings settings-production.json"
  },

Regardless, that .meteor/nightwatch.json config file continues to prove its worth. Weā€™ve managed to walk at least one app from Spark to Blaze and now to React; and another on its way from PHP to React.

1 Like
29

StarryNight 3.10.0 - Release Notes
With the improved NPM integration since Meteor 1.3.x, itā€™s been possible for a few months now to run Nightwatch as a standalone test runner. So with this release, weā€™re focusing on decoupling Nightwatch and StarryNight.

.meteor/starrynight.json
As of 3.10.0, StarryNight now uses a .meteor/starrynight.json config file, which allows .meteor/nightwatch.json to be forā€¦ Nightwatch. The difference between these two files is primarily concerned with where Nightwatch is installed and the directory paths to launch the runner.

If youā€™re using StarryNight, please rename your config file, and rerun the autoconfig script:

cd myapp
mv .meteor/nightwatch.json .meteor/starrynight.json
starrynight autoconfig --nightwatch
1 Like