We Keep Coding

What is the standard way of using selenium in production?

I have written some tests for my website using selenium and javascript. I want to know the standard way of using this script in production. Locally I'm running chrome driver and testing my script. What I have tried is in start of my package.json I run my test node test.js && react-scripts start.What is the standard way of doing the same in production?

In case there is no any difference between running the tests on your local machine and the product environment there is no reason to use your tests differently on the production.
However, it is common to run the tests on production with Jenkins or other CI/CD tools on Unix server in headless mode or with Selenium Grid etc.
In this case you will have to adjust your tests for running with Selenium Grid or in headless mode respectively, to adjust them running on Unix etc.
All this depends on YOUR actual configuration, how YOU will use it.

There are multiple different ways of handling Selenium in production. For example, if you have an open source project, you may consider using GitHub Actions. Here's an example of a JavaScript Workflow from the Selenium Project: https://github.com/SeleniumHQ/selenium/actions/workflows/javascript.yml
That's probably a good place to start, since it is open source and you can see how they run tests. Once you've learned that, you can try out some of the other popular solutions out there if you want (Eg: Jenkins, Azure Pipelines, AWS, Google Cloud, CircleCI, GitLab, TravisCI, etc.)

There is no way for you to use selenium in production, considering that you need selenium in production, such as a crawler, what may be different are your dependencies, in development you will use the dependencies for testing, selenium will use the available driver, either in production or in development/testing.
Perhaps the arguments you use for the chosen browser may be different for the environments used (production, development, etc.), which doesn't make sense to me, because in the test you should reproduce the same scenario as in production.

Ember CLI tests on Sauce Labs

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.

How can I specify the PATH to PhantomJS using GRUNT and QUNIT?

Grunt uses PhantomJS to run headless QUnit tests in a very interesting way (correct me if I'm wrong please). Since I just started experimenting with those tools I don't fully understand it and don't know how to configure nor how to extend it.
I manage to get all working on my machine but I would like to not use the $PATH system variable. Instead, I would like to provide the path to PhantomJS's executable file via a setting which I could easily change and port to other environments.
How can I achieve this?
I suppose there are many ways and I think the Qunit Task from Grunt might have an easy answer. Ideally it would be just a matter of defining the path on the grun.js file, something like this:
qunit: {
phantomjsPath: 'path/to/phantomjs',
files: ['test/**/*.html']
},
My environment is a MacOSX but I accept solutions for any kind of environments like Windows - my build server.
Thanks in advance.
UPDATE The version of Grunt I am using is v0.3.17. The next big version, v0.4.x, has many changes and some are not backwards compatible.

Well I think you finally migrated onto Grunt 0.4. And propably you got grunt-contrib-qunit plugin for running qunit tests under PhantomJS. Unfortunately you'll encountered the same issue - it's not possible to supply path to phantomjs executable. That's because grunt-contrib-qunit/grunt-contrib-phantomjs use phantomjs npm module which downloads PhantomJS on installation and hard-codes path to the executable in its js code. If you're experiencing such an issue then please check my blog post.

Unfortunately, grunt 0.3.x doesn't have a built-in option to specify a path to phantomjs -- it just executes phantomjs directly on the command line. Take a look at this helper function:
https://github.com/gruntjs/grunt/blob/master/tasks/qunit.js#L231
The situation seems to have changed in the has-yet-to-be-released grunt-0.4, however:
https://github.com/gruntjs/grunt-lib-phantomjs/blob/master/lib/phantomjs.js#L22
As you can see, the next version of grunt uses the npm module phantomjs which "exports a path string that contains the path to the phantomjs binary/executable.". Since the npm module phantomjs is installed locally by grunt, it seems like this would avoid you having to worry about setting the PATH variable or installing a conflicting version of phantomjs.
Anyway, I'd consider taking a look at grunt-0.4 if you're willing to live on the bleeding edge.
Otherwise, you can always fork the qunit task and modify the grunt-qunit task to look at your custom configuration variable.

Javascript unit-testing for Rails 3.1 and asset pipeline

I'm looking for the easiest possible Javascript unit-testing system for Rails 3.1 that is specifically capable of working with the asset pipeline out of the box.
I've tried various incarnations of the jasmine gem, including jasmine-rice, headless-jasmine-webkit. Jasmine gem does not appear to work with rails 3.1 out of the box, requiring tweaking of various config files. Jasmine-rice and headless-jasmine-webkit both have complicated dependencies and require more tweaking of the config file.
Any suggestions? Ideally I would need to include HTML/HAML fixtures, and be headless, but at this point I would be happy with anything that allows me to test my javascript with minimal configuration.

Jasmine is the best solution. We're using this to test all our JS code. It works beautifully with CoffeeScript as well.
But don't install the version of RubyGems.org (it's not been updated in a while), just get the latest from github, e.g. add to your Gemfile:
group :test do
gem 'jasmine', :git => 'https://github.com/pivotal/jasmine-gem.git'
end
Then you can run rake jasmine and go to http://localhost:8888 to run your tests. Headless webkit also works.

I was looking for something that would allow me to unit and functional test my javascript within MS Test in visual studio. Took me forever but I found WatiN. What WatiN will do is open internet explorer and run a web page. If you run your IDE as an administrator you can even open local HTML files.
I am currently using it with Visual Studio to run functional and unit tests on all my javascript. I think that so far this is the best solution out of the box for running javascript functional tests from your IDE. For my unit tests I used YUI test, but since you are opening a browser and running javascript within the browser you can use any javascript test framework you want (like qUnit).

I've been using QUnit, a simple yet effective Unit Testing library built on jQuery:
http://docs.jquery.com/QUnit

Hopefully late is better than never... I just wrote a small library that should solve your problem:
https://github.com/proxv/qlive-rails
It injects qunit and your qunit tests into live server responses. It also lets you set state server-side in advance of the tests (like logging in a user and setting content for the page) to reduce client-side mocking.
If you are using rspec, there's also an add-on that will run the qunit tests headlessly along with your other rspec examples.

How can we run JavaScript jasmine tests from Jenkins (Hudson) without loading a JSP?

We have a rich web client. Our controllers and service facades are written in coffeescript (JavaScript) and jquery. In the past they would have been java.
To run our JavaScript jasmine tests from Jenkins/Hudson, we use java's junit and htmlunit to load a test oriented jsp page which includes the jasmine specs.
When the Htmlunit tries to run, it blows up trying to getPage() probably because of an XML parser class path which is extremely challenging to track down in our world.
We just want to be able to run our JavaScript tests from Jenkins and have it report failure if a JavaScript test does not pass. We are just using jsp and htmlunit in order to run JavaScript tests. Can we load the JavaScript tests and javascript code into a JavaScript engine with Jenkins as the thing that kicks it off? If so, how?

Sounds like you're in a Java environment. My jasmine-maven-plugin might be a good fit.

Jasmine Reporters would also be a solution. It has instructions for running headlessly via PhantomJS for example, and it can generate JUnit XML so Jenkins can understand the test results natively, graphing test count, duration, and failure over time.
Also, the "xvfb-run" wrapper often provided with xvfb is a great help here, so you can do "xvfb-run phantomjs.runner.sh ..." in a truly headless environment.

I've previously solved this problem by running the tests with a node.js plugin called jasmine-node
This solution of course requires node.js and a few node modules to properly run the jasmine tests. There is no real browser running the tests, but an emulated one using a module called jsdom, which basically creates a headless browser, and more specifically, a DOM, which the tests can interact with.
There's node modules for jQuery, underscore and propably other too, so these can be tested too. You can even skip the whole browser emulation if you'd rather run the tests in a browser, though I find it too cumbersome compared to automated Jenkins testing.
jasmine-node generates jUnit test reports, which Jenkins can interpret just fine.
I just realized there is some jenkins-jasmine-node plugin that might ease this process.

Grunt is your friend
use grunt http://gruntjs.com/
with grunt jasimine https://github.com/gruntjs/grunt-contrib-jasmine
with nodejs http://nodejs.org/
on jenkins using https://wiki.jenkins-ci.org/display/JENKINS/NodeJS+Plugin
got this setup and it's really nice, plus this gives you a place to start making your build server do other nice things such as deployment, unit testing, etc you know, other nice things

Can you use selenium? That would actually use a real browser then and get as close to the real environment as possible.