Nightwatch: CoffeeScript support?

[suprMax]

Hi!

I'm trying to make my tests run with coffeescript, but it seems to append .js to the end of the file so test.coffee.js can't be run for obvious reasons. How does one use coffeescript with nightwatch?

P.S. I'm following the documentation, after creating nightwatch file and trying to run it here's what I get:

It looks like it doesn't work with the default configuration you have there out of the box

Thanks!

[davidlinse]

How does one use coffeescript with nightwatch?

(Thankfully) Not at all .. At least not without compiling before ..

[suprMax]

Ah, I see. You want to prevent people from using it with your library? Would you mind making it work?

[beatfactor]

No, no one is preventing you from using coffee script, but you'll have to compile it to js.

[suprMax]

I'd prefer to run coffee directly. I was thinking about adding a --require 'coffee-script/register' but unfortunately nightwatch automatically adds .js extension so I can't run coffee files that way. Maybe you could make that optional?

[beatfactor]

I'm not sure how that would work but I don't have much experience with coffeescript. What do you mean by adding a --require? Nightwatch looks for files ending in .js in the test folder to be loaded.

[davidlinse]

why not simply pre-compiling the coffee files and run nightwatch
afterwards? imho nightwatch should not be responsible for this..
my two cents..
~david

[traviscosgrave]

I've been using CoffeeScript since I started with Nightwatch. My IDE
(IntelliJ family) transpiles the coffee on the fly. It duplicates the
files, but works pretty seamlessly.

I can see how it would be useful to skip the transpiling step. If a team is
using coffee and only making the js on build, then their UI tests require
different treatment than their application code, mostly an annoyance. To
further that idea, grunt will accept a coffee file directly as it's config,
a behavior which leads to this kind of question.

Having nightwatch accept coffee natively seems pretty straight forward (
http://stackoverflow.com/questions/7337495/can-i-run-a-coffee-file-directly-from-node-js).,
but I suppose the problem is then looking for js, coffee and litcoffee
files for tests, commands assertions and globals.

My team is working to use test plans written in markdown as litcoffee files
to test our application.
On Aug 8, 2014 9:03 AM, "David Linse" [email protected] wrote:

why not simply pre-compiling the coffee files and run nightwatch
afterwards? imho nightwatch should not be responsible for this..
my two cents..
~david

—
Reply to this email directly or view it on GitHub
https://github.com/beatfactor/nightwatch/issues/224#issuecomment-51597160
.

[suprMax]

Thank you for your input @davidlinse.

@beatfactor mocha, gulp and browserify simply allow you to specify extensions you want to automatically require. adding require 'coffee-script/register' in the command you use to run nightwatch should just require that module and that will overload require and allow you to run coffee files.

Gulp implements it via this https://github.com/tkellen/node-liftoff along with this https://github.com/tkellen/node-interpret. I suppose just using the last one is sufficient and rather easy as well.

[traviscosgrave]

@suprMax I've started to look into what this will take.

As far as I can tell, there are a few required changes.

The first is in the _clirunner.js file where default configs are figured out. The existing method for deciding which file to use if one is not specified looks for defined config files. It looks like grunt is using findup and glob to work with files and it takes the following syntax: filename.{js,coffee}

The second place is in the run.js file in the runFiles function. The function checks for .js as the file extension. This in probably an easy change.

The final place where things can be updated to make coffee (an other scripts) possible is in the api.js file. It looks like this is where the custom commands, assertions and pageObjects are loaded in. Each time the files are loaded, their file extension is validated to be .js. So updating what can be loaded here would complete the enhancement.

I haven't contributed to many projects, and it seems like this enhancement could result in a different package being used (glob vs path vs findup etc). So, I'm not totally comfortable suggesting too many changes.

I did try out just using the regex /\.(js|(lit)?coffee)$/ and added .coffee files to the files found in test and things were still working.

As an aside, if this enhancement is viable, it might be worth adding a config switch/cli parameter, to ignore or include certain types of files to avoid duplicating tests etc for those projects with auto transpile coffee etc.

[beatfactor]

Yeah, that should do it. You can include/exclude file types using the filter/exclude config options in your nightwatch.json.

[traviscosgrave]

Interesting, that hasn't even crossed my mind. I'll take a look at how that
might be leveraged in a more general way in case some one is thinking about
typescript or coco or some other compiled-to.
On Aug 11, 2014 6:52 AM, "Andrei Rusu" [email protected] wrote:

Yeah, that should do it. You can include/exclude file types using the
filter/exclude config options in your nightwatch.json.

—
Reply to this email directly or view it on GitHub
https://github.com/beatfactor/nightwatch/issues/224#issuecomment-51765991
.

[traviscosgrave]

I'm looking at using the filter/exclude feature to allow for choosing which files to run tests against, and I've run into a setting in the run.js called filename_filter that doesn't seem to be implemented. @beatfactor or @davidlinse do you know anything about it? I take that back, it looks like it's a filter specific environment settings?

[beatfactor]

that's being used when you specify the --filter option in the command line.

[traviscosgrave]

ok, then how does it differ from test_settings.filter? I see them being used differently, but don't quite see the flow.

[beatfactor]

--filter is just applied on the file name, test_settings.filter is applied on the entire path.

[traviscosgrave]

Commited Pull Request #231 which might be a reasonable way to go about this.

[lacymorrow]

My $0.02 :
Nightwatch is already a strong JS testing framework.
A very tiny minority would be interested in Coffee support, JS is overwhelming majority.
If you know Coffeescript, you know JS.
No reason to focus efforts on catering to the 1%.
I agree it would be a "nice" feature but I really think it's overkill to be focusing on something like this so early in Nightwatch's lifetime, especially with more important things to focus on.

At the very most, if this were to be implemented it should just have nightwatch pre-compile coffee files into JS, then just execute as normal.

[suprMax]

Are we really the 1%?

[lacymorrow]

Probably less :)

I'm not saying anything about the merits of Coffee, or that I wouldn't prefer using it for Nightwatch, just that "everyone" knows JS, Nightwatch has much bigger issues to fix, and if you want you can write your tests in coffee and compile them yourself.

It wouldn't be too difficult to implement, but it shouldn't be a priority.

[beatfactor]

Nightwatch has much bigger issues to fix

Like what? :)

[lacymorrow]

Sorry for the book :8ball:

First I would say the documentation (which is great) needs one last comb through. I've found a few typos and mis-named functions (maximizeWindow is documented as resizeWindow for example). It needs more code samples and examples of different but common use cases. The documentation is still better than webdriver.io or the regular selenium-python binding docs.

Stability and portability are also some of the biggest requirements and, while nightwatch holds it's own in the selenium world, it's not perfect or even great. I chose to use Nightwatch because I created the same test in Intern, WebDriver.io, Nightwatch and basic selenium-python bindings and got them running in FF/OSX. Taking the same tests and platforms to a windows machine with Chrome/FF/IE, WebDriver and Intern both crash/don't control browsers properly or even fail to start (even though intern-geezer claims to be created for IE6). Nightwatch (and the python bindings ) was the only framework to actually "work" without tweaking when moved to a new system. It still has issues though: In WinServer2003 FF opens and then nightwatch hangs forever. In other setups various problems occur. In an AWS instance of WinServer2008, Auto-starting the server works fine. Running the same test in another fresh install of WinServer2008 the Auto-start just hangs and crashes. These little inconsistencies are often the reason for abandoning a selenium platform and should be tested and ironed out on as many combinations of systems as possible.

IE support. Nightwatch already is a frontrunner in terms of IE stability but as with all Selenium frameworks, it has it's various shortcomings when it hits IE. As much as we developers wish, the need to test and support IE is not going away and Selenium is our mean to that end. Old IE versions will always be an absolute horror to test upon (problems with Server, IEdriver, timing issues, etc.) and that means the framework which can work around these problems best will be the most adopted. Personally I was leaning towards using Intern (geezer branch) until I ran my comparison test above. Nightwatch currently does an excellent job but it could still do better. Passing the same test 9/10 times is (for many) unacceptable. Though it should have been addressed in the Server or the IEDriver, the weight has fallen upon the framework to accommodate for IE's black magic.

AJAX-aware. One of the reasons Angular's Protractor test framework is so stable/fast is that it is aware of the JS execution chain and knows when the DOM has finished being updated and it ready to be tested. Nightwatch obviously doesn't have the luxury of such internal knowledge so it should try to make assumptions about program state when possible/reasonable. For example, don't try to click while page is scrolling/element is in one-time transition/page is loading a resource. I don't know where to draw the line.

Lastly, new features. Parallel browser tests? sweet. Wrappers for Selenium functions? Awesome. There are so many other things that Nightwatch could offer to set it apart from other frameworks. Accommodate for common use cases and make them standard features. Lots of people use CI for testing, maybe show examples of jenkins integration. Things like maximizeWindow function? Underrated and awesome. Features like Auto-start Server, Parallel testing and JUnit output are some of the reasons why Nightwatch is the best JS Selenium framework.

[PandaWhisperer]

+1 for CoffeeScript support. #WeAreTheOnePercent

[johanbrook]

I think supporting drop-in CoffeeScript is a super cool thing for OSS projects to do (even more so for larger ones like Nightwatch). Every time less effort is needed from the user (here, the developer) to get things done, it's a good thing. CoffeeScript is nowadays such a large thing that it's hard to ignore it. Many major frameworks supports it out of the box, and so should Nightwatch. Writing tests in CoffeeScript is really much more readable imo, and removes the cruft of parentheses, braces, etc.

I'd really like to see this happen.

[digitalsadhu]

This is not just a coffeescript issue. Mocha and friends support a standard interface for transpilation (as mentioned above) allowing you to use a transpilation step of your choosing (eg. es6 support via babel/6to5)

From the mocha docs:

--compilers :,... use the given module(s) to compile files

Examples:

//coffeescript
mocha --compilers coffee:coffee-script/register -R spec

//es6
mocha --compilers js:babel/register -R spec

IMO this type of interface would be great to support!

[egorvas]

+1

[peleteiro]

+1

[argyleink]

+1

[Zolmeister]

+1

[davidlinse]

@beatfactor what about a _final_ statement for this subject ?

[beatfactor]

I'm considering adding support for --compilers option, like Mocha does.

[vid]

+1 for es6 support.

[jimmyeisenhauer]

+1 es6 support

[gilnahmias]

+1 for es6 support.

[mikesub]

:+1: for babel transpiling

[mmahalwy]

Anything on this? This would be awesome!

[akralj]

+1 for coffeescript support. thanks :)

[listepo]

+1

[johnapost]

+1

[inancgumus]

@beatfactor I think that you might support generic transpiling by implementing an extensible architecture for others to develop it outside of nightwatch repo.

[pawelwieladek]

+1 for babel

[listepo]

Babel :+1:

[joshystuart]

+1 Babel

[digitaldesigndj]

+1

[hotstone]

+1 for Babel/ES2015 support

[piotr-sobczyk]

+1

[MartinBucko]

+1 for coffee ;)
I have complete app in coffee script, so why write ONLY test in JS? It think there is easy way to precompile coffee before run test to JS..
Thaks

[MartinBucko]

Simple workaround to load test written in coffeescript to nightwatch (with mocha)
nightwatch -c ./.meteor/nightwatch.json -e chrome --test tests/nightwatch/test.js

in tests/nightwatch/test.js

// nighwatch using coffeescript 
require('coffee-script/register');
module.exports = require('./test.coffee');

in tests/nightwatch/test.coffee

describe 'Page test', ->
  it 'browse..', (client) ->
     client.url('http://localhost:3000/').assert.containsText('h1', 'Welcome')
     return 
 return 

[Nic128]

+1

[greyarch]

+1 Coffeescript

[Fire-Dragon-DoL]

Faced this bug too, I can't understand why file inclusion isn't configurable. I can't understand which file will be loaded first in this way.

[FranzSkuffka]

+1

[andrewhl]

+1

[tarajane]

+1 for --compilers support