I have a JS/Node based CLI that was initially developed to run on macOS and Linux. I now want to make it work on Windows, but because of complicated and fixed reasons I have to achieve this without changing the app's source code.
A first step was to lie to the program about its process.platform, which works great by messing with its Module (suggested by #estus) and wrapping the original CLI in another CLI that is then actually used on Windows.
Now I stumbled over some code that runs shelljs.which('ruby') and compares the result to a specific string (/usr/bin/ruby) and outputs an error message or even fails the program when it does not match. I don't know how to overcome that yet.
How can I manipulate what shell.which() returns?
One approach that I could take would be to manipulate require('shelljs') to load my own fork of shelljs that returns whatever I want (via using override-require, which I already used to replace child_process with cross-spawn which works much better on Windows). But I want to avoid maintaining my own fork of shelljs of course - it would be much more practical if I could somehow just manipulate shelljs.which.
I created a super small demo project that is similar to the CLI I am using and can be used to experiment with possible solutions: https://github.com/janpio/nodejs-cli-wrongruby - fake.js would be where I would want to manipulate shelljs.which somehow.
With the help of #Berdi in the comments I figured out that, similar to how I can mess with process.platform, I can also mess with the shelljs.which method:
// Manipulate shelljs.which('ruby')
const shelljs = require('shelljs')
var original_which = shelljs.which
var new_which = function(cmd) {
if(cmd == 'ruby') {
return "/usr/bin/ruby"
}
return original_which.call(this, cmd)
}
shelljs.which = new_which
require("./index.js");
(This assumes the original CLI lives in ./index.js)
Here all calls to shelljs.which with the parameter ruby are answered with /usr/bin/ruby, and all the others requests are sent to the actual shelljs.which implementation.
Related
My team has had the occasional problem of developers pushing Karma/Protractor tests containing the .only() function call, which of course makes our Jenkins etc only run that particular test, potentially allowing bugs to slip by. As such I thought I'd try and figure out a way to stop this from happening without being discovered.
First, I thought I'd look into simply using JSHint to point out the function call, but I can't seem to find a way to do that. I also looked at ESLint for its custom plugins, but I can't figure out how to write a plugin for this particular case.
Could you guys give me some ideas on how to solve this issue? Alternative solutions are also appreciated, of course!
Here's a (probably not working example) of how to create a plugin that flags an error if the parser ever sees a only() call. Again, mileage may vary, but it should be enough to get you started. This does not work if it sees a.only(), we'll leave that up to you.
module.exports.rules = {
"no-only-call": context => ({
CallExpression: (node) => {
if(node.callee.name == "only"){
context.report(node, 'Calls to only() are disallowed');
}
}
})
};
https://www.kenneth-truyers.net/2016/05/27/writing-custom-eslint-rules/ - Simple example of creating a custom rule
http://esprima.org/demo/parse.html - Use this online parser to help you understand the parse tree.
https://www.npmjs.com/package/generator-eslint - Use this generator to start your plugin project
I tried something like:
var path = '../right/here';
var module = require(path);
but it can't find the module anymore this way, while:
var module = require('../right/here');
works like a charm. Would like to load modules with a generated list of strings, but I can't wrap my head around this problem atm. Any ideas?
you can use template to get file dynamically.
var myModule = 'Module1';
var Modules = require(`../path/${myModule}`)
This is due to how Browserify does its bundling, it can only do static string analysis for requirement rebinding. So, if you want to do browserify bundling, you'll need to hardcode your requirements.
For code that has to go into production deployment (as opposed to quick prototypes, which you rarely ever bother to add bundling for) it's always advisable to stick with static requirements, in part because of the bundling but also because using dynamic strings to give you your requirements means you're writing code that isn't predictable, and can thus potentially be full of bugs you rarely run into and are extremely hard to debug.
If you need different requirements based on different runs (say, dev vs. stage testing vs. production) then it's usually a good idea to use process.env or a config object so that when it comes time to decide which library to require for a specific purposes, you can use something like
var knox = config.offline ? require("./util/mocks3") : require("knox");
That way your code also stays immediately traversable for others who need to track down where something's going wrong, in case a bug does get found.
require('#/path/'.concat(fileName))
You can use .require() to add the files that you want to access calculating its path instead of being static at build time, this way this modules will be included and when calling require() later they will be found.
What's the most performant way to execute JS directly after a HTTP request in JRuby? I know about all the test frameworks like HtmlUnit, Celerity, Capybara + PhantomJS == Poltergeist, CasperJS etc. but they're still test frameworks.
What I need is a simple way to execute all JS code which is included in HTML after fetching the URL e.g. by Net::Http.
First of all, it goes with out saying: DON'T DO THIS IN PRODUCTION!
Executing some script that's been pulled from somewhere on the internet is a recipe for disaster. If you're using it as part of your testing infrastructure, it may be of some use but I'd guess that there's a simpler way to solve your problem.
To answer the more general question, here's how you'd initialize a JavaScript engine bundled with JDK 1.6+ (effectively a cut down version of Rhino, although this will change in Java 8 probably):
import javax.script.ScriptEngineManager
import javax.script.SimpleBindings
manager = ScriptEngineManager.new
engine = manager.getEngineByName("JavaScript")
bindings = SimpleBindings.new
bindings['x'] = 1
engine.eval("print(x)", bindings)
Getting your engine to evaluate any dependencies like jQuery is left as an exercise to the user. Have a look at the javax.script JavaDoc.
If you need more control over the evaluation environment you'll have to use Rhino directly, or wait for Nashorn...
I'm trying to run envjs and Rhino in a java application to render SVGs with D3.js.
So far, I can evaluate smaller functions using Rhino but when it comes to setting up envjs, the problems begin. The most important one is that the only tutorial for envjs talks about a file called env.rhino.js. But I have no idea where to find it.
Can anybody help me out?
(Yes, google shows some results but they are not officially belonging to Rhino or envjs)
I know this answer is very late. But I want to do the same and had the same problems - maybe this will help the next one. It took a while to figure out which one of the hundrets of github forks on env-js will do the job. I found out that this combination will work for a simple test:
git clone https://github.com/thatcher/envjs-site.git
#note the different fork!
wget https://raw.github.com/thatcher/env-js/master/src/dom/sizzle.js
wget http://d3js.org/d3.v3.min.js
java -jar dist/env-js-1.1.jar
load("lib/env.rhino.js");
load("sizzle.js");
load("d3.v3.min.js");
d3.select("body").append("svg").selectAll("line").data([1,2]).enter().append("line").attr("x1", function(d){return d;});
document.innerHTML;
<html><head/><body><line/><line/><svg xmlns="http://www.w3.org/2000/svg"><line x1="1"/><line x1="2"/></svg></body><line/><line/></html>
j
First, download env.rhino.js.
Then, use this Java code to start a Rhino instance and load Env.js:
import org.mozilla.javascript.Context;
import org.mozilla.javascript.tools.shell.Global;
import org.mozilla.javascript.tools.shell.Main;
Context cx = Context.enter();
Global scope = new Global(cx);
cx.setOptimizationLevel(-1);
cx.setLanguageVersion(Context.VERSION_1_5);
Now you can load and run a JavaScript file (using its absolute file-system path)
Main.processFile(cx, scope, ABSOLUTE_PATH_TO_SOME_JAVASCRIPT_FILE);
And/or evaluate JavaScript code and get its String result
(String)cx.evaluateString(scope, "alert('Its WORKING!')", "js", 1, null);
I did attempt this but couldn't go very far. I also wanted to generate SVGs on server side, with requests being initiated from java(Glassfish in my case). The only way you can do this is with jsdom & Node.js. I am able to do this successfully. Sadly, other than Node.js + jsdom, there seems no other way to do this.
Once you get it working, there are bigger problems lurking if you try to heavily load Node.js with SVG generation requests.
This might sound a little dumb, but I'm actually a bit confused how to approach JavaScript testing for web frontends. As far as I'm concerned, the typical 3-tier architecture looks like this:
Database tier
Application tier
Client tier
1 is of no concern in this question. 2 contains all the program logic ("business logic") 3 the frontend.
I do test-driven development for most projects, but only for the application logic, not the frontend. That is because testing the UI is difficult and unusual in TDD, and normally not done. Instead, all application logic is separated from UI, so that it is simple to test that logic.
The three tier architecture supports this: I can design my backend as a REST API which is called by my frontend. How does JS testing fit in? For the typical three-tier-architecture, JS (i.e. JS on the client) testing doesn't make much sense, does it?
Update:
I've changed the question's wording from "Testing JavaScript in web frontends" to "Test-driven development of JavaScript web frontends" to clarify my question.
Remember what the point of unit-testing is: to ensure a particular module of code reacts to some stimuli in an expected manner. In JS, a significant portion of your code, (unless you have some lifecycle framework like Sencha or YUI) will either be directly manipulating the DOM or making remote calls. To test these things, you simply apply traditional unit-testing techniques of dependency injection and mocking/stubbing. That means you must write each function, or class, that you want to unit-test to accept mocks of the dependent structures.
jQuery supports this by allowing you to pass an XML document into all traversal functions. Whereas you might normally write
$(function() { $('.bright').css('color','yellow'); }
you'll instead want to write
function processBright(scope) {
// jQuery will do the following line automatically, but for sake of clarity:
scope = scope || window.document;
$('.bright',scope).css('color','yellow');
}
$(processBright);
Notice we not only pull the logic out of the anonymous function and give it a name, we also make that function accept a scope parameter. When that value is null, the jQuery calls will still function as normal. However, we now have a vector for injecting a mock document that we can inspect after the function is invoked. The unit-test could look like
function shouldSetColorYellowIfClassBright() {
// arrange
var testDoc =
$('<html><body><span id="a" class="bright">test</span></body></html>');
// act
processBright(testDoc);
// assert
if (testDoc.find('#a').css('color') != 'bright')
throw TestFailed("Color property was not changed correctly.");
}
TestFailed could look like this:
function TestFailed(message) {
this.message = message;
this.name = "TestFailed";
}
The situation is similar with remote calls, though rather than actually injecting some facility, you could get away with a masking stub. Say you have this function:
function makeRemoteCall(data, callback) {
if (data.property == 'ok')
$.getJSON({url:'/someResource.json',callback:callback});
}
You would test it as such:
// test suite setup
var getJSON = $.getJSON;
var stubCalls = [];
$.getJSON = function(args) {
stubCalls[stubCalls.length] = args.url;
}
// unit test 1
function shouldMakeRemoteCallWithOkProperty() {
// arrange
var arg = { property: 'ok' };
// act
makeRemoteCall(arg);
// assert
if (stubCalls.length != 1 || stubCalls[0] != '/someResource.json')
throw TestFailed("someResource.json was not requested once and only once.");
}
// unit test 2
function shouldNotMakeRemoteCallWithoutOkProperty() {
// arrange
var arg = { property: 'foobar' };
// act
makeRemoteCall(arg);
// assert
if (stubCalls.length != 0)
throw TestFailed(stubCalls[0] + " was called unexpectedly.");
}
// test suite teardown
$.getJSON = getJSON;
(You can wrap that whole thing in the module pattern to not litter the global namespace.)
To apply all of this in a test-driven manner, you would simply write these tests first. This is a straightforward, no frills, and most importantly, effective way of unit-testing JS.
Frameworks like qUnit can be used to drive your unit-tests, but that is only a small part of the problem. Your code must be written in a test-friendly way. Also, frameworks like Selenium, HtmlUnit, jsTestDriver or Watir/N are for integration testing, not for unit-testing per se. Lastly, by no means must your code be object-oriented. The principles of unit-testing are easily confused with the practical application of unit-testing in object-oriented systems. They are separate but compatible ideas.
Testing Styles
I should note that two different testing styles are demonstrated here. The first assumes complete ignorance of the implementation of processBright. It could be using jQuery to add the color style, or it could be doing native DOM manipulation. I'm merely testing that the external behavior of the function is as expected. In the second, I assume knowledge of an internal dependency of the function (namely $.getJSON), and those tests cover the correct interaction with that dependency.
The approach you take depends on your testing philosophy and overall priorities and cost-benefit profile of your situation. The first test is relatively pure. The second test is simple but relatively fragile; if I change the implementation of makeRemoteCall, the test will break. Preferably, the assumption that makeRemoteCall uses $.getJSON is at least justified by the documentation of makeRemoteCall. There are a couple more disciplined approaches, but one cost-effective approach is to wrap dependencies in wrapper functions. The codebase would depend only on these wrappers, whose implementations can be easily replaced with test stubs at test-time.
There is a book titled Test-Driven JavaScript Development by Christian Johansen that might help you. I have only looked at some of the samples in the book (just downloaded a sample to Kindle the other day) but it looks like a great book that addresses this very issue. You might check it out.
(Note: I have no connection with Christian Johansen and no investment in sales of the book. Just looks like a good thing that addresses this problem.)
I have a similary architected application with JS client tier. In my case i use our company's own JS-framework to implement client tier.
This JS framework is created in OOP-style thus i can implement unit-testing for core classes and components. Also, to cover all user interactions (which can't be covered using unit-testing) i am using Selenium WebDriver to do an integration testing of framework visual components and test them under different browsers.
So, TDD can be applied to JavaScript development if code under test is written in OOP-manner. Also integration test is also possible (and can be used to do some kind of TDD).
Have a look at QUnit, as well, for unit tests of JavaScript methods and functions.
You can test your application from a user perspective with tools such as Rational Functional Tester, the HP tools or other equivalent software.
These tools test the application as if a user was sitting in front of it, but in an automated fashion. This means that you can test all three tiers at the same time, and especially the Javascript which may be difficult to test otherwise. Functional testing like this may help to find UI bugs and quirks with how the UI is using the data pushed out by your middle tier.
Unfortunately these tools are very expensive, so there may be other equivalents (and I'd be interested to know of such tools).
In our company we use jsTestDriver. It's a feature rich environment for testing frontend.
Take a look at it.