CasperJS test doesn't return after execution - casperjs

I'm having a problem getting casperjs test to exit after execution, I have to hit CTL-C to exit execution. I'm on OSX 10.7 with casperjs 1.1 devel.
To test this wasn't my code I simply copied this sample from the docs:
var casper = require("casper").create();
function Cow() {
this.mowed = false;
this.moo = function moo() {
this.mowed = true; // mootable state: don't do that at home
return 'moo!';
};
}
casper.test.begin('Cow can moo', 2, function suite(test) {
var cow = new Cow();
test.assertEquals(cow.moo(), 'moo!');
test.assert(cow.mowed);
test.done();
});
And I get the following output
casperjs test cow-test.js
Test file: cow-test.js
# Cow can moo
PASS Subject equals the expected value
PASS Subject is strictly true
I then have to hit CTL-C to stop execution. Am I missing something to stop execution?

Per https://github.com/n1k0/casperjs/issues/593#issuecomment-23062361, the problem was that I had created a casper instance at the top of the file, which the documentation warns you not to do.
The solution was to remove the var casper = require("casper").create(); line.

Related

google script can you use the IDE debugger to step through debug a called google script library

I have a google doc script that executes a function in a google script library I created (Call - calls Lib1.lib1function() ). I'm wondering if I set a breakpoint in the IDE debugger in the google doc script where I'm making a call to a function in the library script and get the debugger to expose the execution of the library function. ie. keep tracking execution in the called library. Or is my only debugging technique in the script library, Logger.log() and writing info to the console?
The only other debugging solution I can think of is to copy the actual library script (Lib1) to a new Google Doc script file and test and execute the code there. Once I'm done creating and testing the code, I would then copy it back to the library script for other docs to use.
Unfortunately, you cannot debug a library on another project. The optimal way to debug a library is to create another function in your library script that will call the library method or create unit tests.
Here I used QUnit to create unit test for my library method sumArray.
QUnit.helpers(this);
function sumArray(arr) {
var sum = 0;
for ( var i = 0; i < arr.length; i++ ){
if(isNaN(arr[i])){
return "Non-numerical data detected";
}else{
sum = sum + arr[i];
}
}
return sum;
}
function testFunction(){
testingSumArray();
}
function testingSumArray(){
QUnit.test( "sumArray testing", function() {
expect(2);
equal( sumArray([1,2,3,4,5]), 15 , "Test for Array [1,2,3,4,5], Output is 15" );
equal( sumArray([1,'a','b','c',4]), "Non-numerical data detected", "Test for Array [1,'a','b','c',4]: Output is Non-numerical data detected" );
});
}
function doGet( e ) {
QUnit.urlParams( e.parameter );
QUnit.config({ title: "sumArray Unit tests" });
QUnit.load( testFunction );
return QUnit.getHtml();
};
Output:
To learn how to use QUnit in Apps Script, you can check the documentation here.

InDesign Server Crashing on Data Merge

I'm trying to do a very basic data merge with InDesign Server and keep getting a crash.
I begin the server with ./InDesignServer -port 18383 starts with no problems.
I call the script with ./sampleclient ./scripts/test.jsx
The .jsx looks like this:
var source = File("/Users/me/Desktop/InDesign Server/example/example.indd")
var destination = File("/Users/me/Desktop/InDesign Server/example/example.pdf")
var sourceData = File("/Users/me/Desktop/InDesign Server/example/example.csv")
var doc = app.open(source);
doc.dataMergeProperties.selectDataSource(sourceData);
doc.dataMergeProperties.dataMergePreferences.recordNumber = 1;
doc.dataMergeProperties.mergeRecords(); // <-- Crashes here
var myPDFExportPreset = app.pdfExportPresets.item(0);
app.documents.item(0).exportFile(ExportFormat.pdfType, destination, false, myPDFExportPreset);
app.documents.item(0).close(SaveOptions.no);
doc.close(SaveOptions.no);
InDesign Server responds with:
Tue Sep 18 09:48:21 2018 INFO [javascript] Executing Script
./InDesignServer: line 13: 30363 Segmentation fault: 11 "$installed_name" "$#"
And crashes. This script runs perfectly fine in InDesign CC Desktop. Server appears to crash on the .mergeRecords() call. Any ideas why?
Edit: I've modified the code to 1) Have no spaces in the file path 2) check that my objects all exist before performing the merge.
var source = File("/Users/me/Desktop/example/example.indd");
var destination = File("/Users/me/Desktop/example/example.pdf");
var sourceData = File("/Users/me/Desktop/example/example.csv");
var doc = app.open(source);
doc.dataMergeProperties.selectDataSource(sourceData);
if (source.exists && destination.exists && sourceData.exists) {
try {
app.consoleout("Performing merge...");
doc.dataMergeProperties.mergeRecords(); // <-- Crashes here
} catch (err) {
app.consoleout(err);
}
} else {
app.consoleout("Something doesn't exist...");
}
It logs "Performing merge..." so my file paths do in fact point to files that exist. What's more, it full on crashes, and does not report any errors.
Edit 2:
It should be noted, this is the error the Terminal window which launched sampleclient gets from IDS: Error -1 fault: SOAP-ENV:Client [no subcode]
"End of file or no input: Operation interrupted or timed out"
Detail: [no detail]
The folks at Adobe took notice, and fixed this issue for the 2019 release of InDesign Server. The same script, with a similar merging document, no longer produces the error.
So, for a solution, update to 2019.
More information:
Adobe Forums Post
Found a solution, if others find themselves in my situation.
Still a mystery why mergeRecords() seems broken in Server.
doc.dataMergeProperties.exportFile()
Props to Colecandoo: https://forums.adobe.com/thread/2478708
My code is now:
var source = File("/Users/me/Desktop/example/example.indd");
var destination = File("/Users/me/Desktop/example/example.pdf");
var sourceData = File("Macintosh HD:Users:me:Desktop:example:example.csv");
var doc = app.open(source);
var myExport = File(doc.filePath + "/" + doc.name.split(".indd")[0] + ".pdf");
doc.dataMergeProperties.dataMergePreferences.recordNumber = 3;
with (doc.dataMergeProperties.dataMergePreferences) {
recordSelection = RecordSelection.ONE_RECORD;
}
app.dataMergeOptions.removeBlankLines = true;
doc.dataMergeProperties.exportFile(myExport, "[High Quality Print]", );
Still takes some tweaking, but it's performing the merge - this is what I needed.

mocha - how do I list files that will be executed

I'm wondering if there is a way to get mocha to list all the tests that it will execute. I don't see any reasonable options when I list them using mocha --help; There are several reporters, but none appear designed to list the files that will be processed (or name the tests that will be run).
The way reporters work is by listening for events dispatched by mocha, these events are only dispatched when running a real test.
A suite contains a list of tests, so there is the info that you need. However, the suite is usually only initialized on run().
If you are ok with running mocha from nodejs instead of from the command line you can create this diy solution based on the code from Using-mocha-programmatically:
var Mocha = require('mocha'),
fs = require('fs'),
path = require('path');
// First, you need to instantiate a Mocha instance.
var mocha = new Mocha(),
testdir = 'test';
// Then, you need to use the method "addFile" on the mocha
// object for each file.
// Here is an example:
fs.readdirSync(testdir).filter(function(file){
// Only keep the .js files
return file.substr(-3) === '.js';
}).forEach(function(file){
// Use the method "addFile" to add the file to mocha
mocha.addFile(
path.join(testdir, file)
);
});
// Here is the code to list tests without running:
// call mocha to load the files (and scan them for tests)
mocha.loadFiles(function () {
// upon completion list the tests found
var count = 0;
mocha.suite.eachTest(function (t) {
count += 1;
console.log('found test (' + count + ') ' + t.title);
})
console.log('done');
});

How to pass variable values to sendKeys in casperjs

I have the following issue with sendKeys in casperjs.
I am trying to pass the port as an option into casperjs and this is working, but when i try to use the port value with casper.cli.get it doesn't work in sendKeys!!!
var casper = require('casper').create();
casper.echo("Casper CLI passed args:");
require("utils").dump(casper.cli.args);
casper.echo("Casper CLI passed options:");
require("utils").dump(casper.cli.options);
if (casper.cli.has("ip") === false) {
casper.echo("Usage: casper.js test modify_port.js --ip=<x.x.x.x> --port=<xxxxx>").exit();
}
if (casper.cli.has("port") === false) {
casper.echo("Usage: casper.js test modify_port.js --ip=<x.x.x.x> --port=<xxxxx>").exit();
}
...
casper.then(function() {
test.assertTextExists("Change", "Data Base - Change - port");
this.sendKeys('input[name="Params.port"]', casper.cli.get("port"));
this.click('input[name="Apply"]');
});
The above way seems not to work and it doesn't give me also no error msg.
But when i hard code the port in the sendKeys line then i see that the port is changed, like:
this.sendKeys('input[name="Params.port"]', '29999');
This is also working fine (hard coded):
var myPort = '29999'
this.sendKeys('input[name="Params.port"]', myPort);
But this again is not working:
var myPort = casper.cli.get("port")
this.sendKeys('input[name="Params.port"]', myPort);
Thanks in adv. for your time
After some more readings I stepped over the part where casperjs documentation is saying about Raw parameter values.
So, I figured out to use my parameter in this way:
this.sendKeys('input[name="Params.port"]', casper.cli.raw.get('port'));
When passing variables into sendKeys they will not appear in the form unless they are preceded with an empty string "".
this.sendKeys("selector", "" + variable);
I guess this may be because sendKeys can only handle variables of type string.
Source

Debugging jasmine-node tests with node-inspector

Does anyone have any idea if this is possible? Most of the sample for node-inspector seemed geared toward debugging an invoked webpage. I'd like to be able to debug jasmine-node tests though.
In short, just debug jasmine-node:
node --debug-brk node_modules/jasmine-node/lib/jasmine-node/cli.js spec/my_spec.js
If you look at the source of the jasmine-node script, it just invokes cli.js, and I found I could debug that script just fine.
I wanted to use node-inspector to debug a CoffeeScript test. Just adding the --coffee switch worked nicely, e.g.
node --debug-brk node_modules/jasmine-node/lib/jasmine-node/cli.js --coffee spec/my_spec.coffee
I ended up writing a little util called toggle:
require('tty').setRawMode(true);
var stdin = process.openStdin();
exports.toggle = function(fireThis)
{
if (process.argv.indexOf("debug")!=-1)
{
console.log("debug flag found, press any key to start or rerun. Press 'ctrl-c' to cancel out!");
stdin.on('keypress', function (chunk, key) {
if (key.name == 'c' && key.ctrl == true)
{
process.exit();
}
fireThis();
});
}
else
{
console.log("Running, press any key to rerun or ctrl-c to exit.");
fireThis();
stdin.on('keypress', function (chunk, key) {
if (key.name == 'c' && key.ctrl == true)
{
process.exit();
}
fireThis();
});
}
}
You can drop it into your unit tests like:
var toggle = require('./toggle');
toggle.toggle(function(){
var vows = require('vows'),
assert = require('assert');
vows.describe('Redis Mass Data Storage').addBatch({
....
And then run your tests like: node --debug myfile.js debug. If you run debug toggle will wait until you anything but ctrl-c. Ctrl-c exits. You can also rerun, which is nice.
w0000t.
My uneducated guess is that you'd need to patch jasmine, I believe it spawns a new node process or something when running tests, and these new processes would need to be debug-enabled.
I had a similar desire and managed to get expressso working using Eclipse as a debugger:
http://groups.google.com/group/nodejs/browse_thread/thread/af35b025eb801f43
…but I realised: if I needed to step through my code to understand it, I probably need to refactor the code (probably to be more testable), or break my tests up into smaller units.
Your tests is your debugger.

Resources