Ember CLI tests on Sauce Labs - javascript

How can I get ember-cli tests running on Sauce Labs? Testem has an example configuration, but I don't know how to translate that into the ember-cli compiled tests since the testem.json gets packed into the build when tests run.
I tried doing an ember build --env=test and then putting "test_page": "dist/tests/index.html" in my testem.js and just running testem ci --port=8080 as it is in the example, but that gives me 0 tests run.

I believe I have this mostly solved (some issues remain with individual browsers). For posterity you can view my solution here*:
The things that seem to be necessary:
Use NVM to manage node on OSX, things only started to work when I stopped having to sudo random junk.
Don't use localhost, I used localtest here for the hostname, but you can use anything - sauce and localhost don't get along very well.
The command is ember test --port=8080 --host=localtest
I put my sauce stuff in a different testem config file so I can still run ember test on my dev machine.
Hopefully having a starting place saves someone else from doing all of the wrong things I did originally.
*You probably don't need all of that, as we're currently using ember-cli api stubs to mock our API during development so we need to run a separate instance of ember serve.

Related

When running `ember test`, execution hangs at `Built project successfully. Stored in ". . .`

I've googled around for an answer but have yet to turn up anything of use. Does anyone know why attempts to run ember test at best result in a message that reads:
Built project successfully. Stored in "/Users/.../tmp/class-tests_dist-H42JePnK.tmp".
If your tests won't run at all, here are a few things to look for:
Check for a testem.js file. It is essential and contains the instructions and configurations that the Ember CLI needs. Deleting it will cause your app to build and 0 tests to run.
Check to make sure your testem.js file is valid/complete. You can test this by doing ember init and then choosing option d (diff) to see what is different between your app and a brand new app.
Your tests are also available in the normal browser. Go to http://localhost:4200/tests and see what happens there. Perhaps it will give some clues.
Similar to above, try ember test --server and see if you get different results.
Create a fresh app with ember new and try doing ember test. It can sometimes be easier to compare a fresh app instead of doing the ember init diffing.
Try switching the browser you are using for testing (unlikely to be the problem in this case, but sometimes works). For example, run the tests with headless Chrome instead of PhantomJS. The most recent release of the Ember ClI has the testem configuration that you need to try headless Chrome.

Version control strategy for webpack-encore project

I'm learning to use webpack-encore and noticed it is installed only as a dev dependency. Does that mean I should compile my js and css files on development and push them to the repository, and then to production?
That seems to me what the docs are implying, but wouldn't that mean a merge-conflict hell? Compiled files would be impossible to merge.
Also wouldn't that be contrary to version control philosophy? As far as I know, you don't publish binaries in compiled languages (i.e. C/C++), you push the code and expect the server to compile them. I know this isn't the same type of "compilation" in javascript, but what is the expected behavior of the production server in this case? To receive the files ready to serve them, or to compile them at the time of release?
Thanks in advance
Does that mean I should compile my js and css files on development and push them to the repository, and then to production?
Not exactly - it depends on how you deploy.
When you deploy, you need to run ./node_modules/.bin/encore production to build your assets. Once you've done this, only your built assets (e.g. web/build) need to be transferred to production.
You could run this command locally (or on some "build" server) and the transfer all the files to production. Or, you could use a git pull on production, and then run this command on production (the downside being that you would need Node.js installed on production).
You shouldn't / don't need to commit your built files to your repository. But... if it simplifies your deploy (i.e. you want to do a git pull and be done), there's no real problem with that.
I just added a PR to answer these in the FAQ (http://symfony.com/doc/current/frontend/encore/faq.html) - here's the PR until it's deployed: https://github.com/symfony/symfony-docs/pull/8109
Cheers!
Solution 1:
Run yarn run encore production locally
Check out which files have been created / modified
Add them to VCS
Commit
Push / deploy
Solution 2:
Push / deploy
Run yarn run encore production remotely during deployment
To my eyes the 2nd solution is way better, because you don't need an extra human-checking before deployment, everything is automated.
But this has a strong drawback: building assets can be a slow process, and when I deploy, my production is down during 5 to 20 seconds until assets are built.
Here's the HTTP 500 error:
An exception has been thrown during the rendering of a template ("Asset manifest file "[...]/web/build/manifest.json" does not exist.").
It looks like the manifest.json file is deleted at the beginning of the process, and created from scratch later on.
Something that should be improved?

Sane approach to build and deploy typescript/node.js application

I'm working on node.js app that is written in Typescript, which means it needs to be compiled to JS before running. As I'm coming from java/jvm background where you ship prebuilt package to server and it gets run there I'm a bit afraid of the way of deployment where you push code to git and it's being built/compiled on server first and then run.
I don't like it for two main reasons:
dev dependencies need to be installed on server
deployment depends on external resources availability (npm etc).
I found NAR https://github.com/h2non/nar which is more or less what I wanted but it has some drawbacks (doesn't work with some deps that have native extensions).
My question is: is there any other "sane" way of doing deployment node.js deployment than this risky combination of npm install and tsc on server? Or should I let that sink in and do it that way?
To be honest I don't believe there are no more sane/reliable options for that.
What you can do (but there are probably other perfectly valid approaches) is building your project locally (or on a CI service), and only deploy this built version when you consider it as valid (tests, etc.).
This way, if something bad happens, like npm that fails, or a compilation error, you don't deploy anything, and you have time to resolve the situation.
For example, I used to have a gulp task (but it can be anything else: Grunt, a simple npm script...) that clone a production repository and build the project into this directory.
That way, I can check that my build is valid. If it is, I make a new commit and push it to the production repo, that is served the way you need (on a Heroku instance for example).
Pros
Clear separation of dev and non-dev dependencies
Deployment only when you know that the build is valid
No built files on source control on the development repository
No "live" dependency on external tasks like npm install or tsc build
Cons
You have two separated git repositories (one with the source code, one with the built version of your project)
Production process is a little bit heavier than simply committing to master
(From comment) Doesn't properly handle the case of npm package that relies on native extensions that have to be (re)built
is there any other "sane" way of doing deployment node.js deployment than this risky combination of npm install and tsc on server
package.json + npm install + tsc is the way to do it. Nothing risky about it.
More
Just use an npm script : https://github.com/TypeStrong/ntypescript#npm-scripts

Running jasmine specs headlessly with phantomjs

I have been using jasmine-headless-webkit to run my jasmine specs on my Rails 3.2 app, but I recently switched over to phantomjs/poltergeist to run my request specs, so I am needing to upgrade my jasmine tests to also run on phantom. I'd like to get away from using xvfb on my CI server.
Does anyone have any good way to run jasmine tests using phantom in the console? I'm finding surprisingly little info about it on the web.
The simplest solution which i found is setup guard-jasmine (Guard::Jasmine outside of Guard) and then add guard-jasmine -u http://localhost:3001/ to your build script. Works pretty well on my jenkins. Also you need to install phantomJS on the server. In my case i needed also node.js

Unit testing in RequireJS and QUnit basics

I am just trying to get my head round unit testing in Javascript and RequireJS. I am building a web-app and obviously only want to have tests run in development not production builds.
Questions:
Do you just test when you want to, or do you have JS tests running
on every page load when in development?
If tests are only on demand
then how do you trigger your tests to run? Query strings (eg.
?testing=true) or something like that?
I just need an idea of how people go about testing in development. I am using BackboneJS, RequireJS and jQuery on the front end with a NodeJS/ExpressJS server on the backend.
For a Backbone project at work we have a maven build process that runs our automated javascript tests through jsTestDriver, and we read the results with Sonar. I usually run the tests manually (with 'mvn test'), but I could easily tell maven every time I save a file, for example. I wrote a post that shows how to integrate QUnit, Requirejs, and code coverage with JSTD that is independent of Maven: js-test-driver+qunit+coverage+requirejs. It also contains links to a QUnitAdapter that is way more up-to-date and developed than the one on the jsTestDriver site. I'll update this post when I manage to write about how I got jsTestDriver working with Maven and Sonar. Hope it helps.
Grunt is a popular JS build tool. There's something called grunt-watch that can monitor certain files for change, and execute tasks accordingly. You could easily run unit tests with something like this on every save.
Usually end-to-end tests take longer, and we use the CI for that. I've seen a presentation on Meteor TDD that does end-to-end tests after every save though.
There are many end-to-end test frameworks, and they can run in a headless browser like phantom js using a build tool like grunt. Some frameworks open an actual browser to run the tests, but run via command line and report results using XML.
If you break out your components enough, the tests could have a small enough scope to run on each save.
For some core code I use JsUnit + Rhino on build server. For more complex bits (usually interface) I use selenium (it also runs on build server). I don't test anything on page load, I only use not-compressed versions of scripts.
I don't any solution for integration tests.

Categories