Why is Console.WriteLine not working in an MSpec assertion? - console

I'm having trouble writing to the console from an MSpec assertion. I'm using v0.5.11 (unsigned) from Nuget. Nothing radical here, but it's not working. Anyone know what I'm missing?
public class When_doing_stuff
{
It should_out_stuff_to_console = () =>
{
var val1 = 1;
var val2 = 2;
(val1 + val2).ShouldEqual(3);
Console.WriteLine(val2);
};
}

I suspect that you actually have a failing assertion in your real code. You posted a passing assertion, which should print just fine (as Alexander and I have both verified locally).
A failing assertion, however, throws a SpecificationException and the Console line would never be executed. You should print before your assertion. For example
It should_out_stuff_to_console = () =>
{
Console.WriteLine(val2);
(val1 + val2).ShouldEqual(3);
}
And the output from the mspec command line runner
cmd> mspec-clr4.exe test.dll
Specs in test:
When doing stuff
Blah
» should out stuff to console
But, I don't recommend printing debug statements to the console from your assertions, or your test run in general. It's going to gum up the test report (as you can see above).

In fact there's nothing wrong with the assertion here, Anthony :-)
I pasted the code user287079 posted into a new Class Library, see what's being printed in my console:
>mspec-clr4 <somewhere>\bin\Debug\ClassLibrary1.dll
Specs in ClassLibrary1:
When doing stuff
2
» should out stuff to console
Contexts: 1, Specifications: 1, Time: 0.11 seconds

Related

How to get OS name while writing gnome-extensions

How to get OS name while writing gnome-extensions..
for example:
GLib.get_real_name()
I have gone through this post How can my GNOME Shell extension detect the GNOME version?
In case of getting the operating system name as found in /etc/os-release, this not particularly related to GJS or extensions.
You could just open the /etc/os-release file directly, but since GKeyFile is not introspectable in GJS you would have to parse it manually. Alternatively you could use the org.freedesktop.hostname1 DBus interface to get the "pretty name", although I don't know if that's guaranteed to be available on all distributions.
const GLib = imports.gi.GLib;
const Gio = imports.gi.Gio;
let osName = 'Unknown';
try {
// NOTE: this is a synchronous call that will block the main thread
// until it completes. Using `Gio.DBus.system.call()` would be
// better, but I don't know if that works for your use case.
let reply = Gio.DBus.system.call_sync(
'org.freedesktop.hostname1',
'/org/freedesktop/hostname1',
'org.freedesktop.DBus.Properties',
'Get',
new GLib.Variant('(ss)', [
'org.freedesktop.hostname1',
'OperatingSystemPrettyName'
]),
null,
Gio.DBusCallFlags.NONE,
-1,
null
);
let value = reply.deep_unpack()[0];
osName = value.unpack();
} catch (e) {
logError(e, 'Fetching OS name');
}
// Example Output: "Fedora 32 (Workstation Edition)" or "Unknown" on failure
log(osName);

meteor-testing tutorial fails

I started the meteor-testing tutorial, but the 2nd automatic generated test fails with:
TypeError: Cannot call method 'url' of undefined
So it seems that the client variable is not defined. Did anybody experience similar issues? (btw is there a way to debug this)
i'm using ubuntu 14.04 with
Meteor 1.2.0.2
node v4.0.0
xolvio:cucumber 0.19.4_1 CucumberJS for Velocity
Update:
Generated test code intests/cucumber/features/step_definitions/sample_steps.js:
// You can include npm dependencies for support files in tests/cucumber/package.json
var _ = require('underscore');
module.exports = function () {
// You can use normal require here, cucumber is NOT run in a Meteor context (by design)
var url = require('url');
// 1st TEST OK
this.Given(/^I am a new user$/, function () {
server.call('reset'); // server is a connection to the mirror
});
// 2nd TEST FAIL
this.When(/^I navigate to "([^"]*)"$/, function (relativePath) {
// process.env.ROOT_URL always points to the mirror
client.url(url.resolve(process.env.ROOT_URL, relativePath));
});
...
};
I was said to file an issue in the chimp repository, where I was pointed to the solution:
// 2nd TEST FAIL
this.When(/^I navigate to "([^"]*)"$/, function (relativePath) {
// REPLACE client with browser
browser.url(url.resolve(process.env.ROOT_URL, relativePath));
});
This is a short fix, but I'm not sure whether you should later rather use client (seems to be wrapper for different environments).
**Update: ** meanwhile this was fixed, no adaption necessary anymore

Protractor, Cucumber and chai as promised: When chai assertion fails

I am using protractor to run my cucumber tests. Inside my test I have the following assertion:
label.getText().then(
function(labelText){
labelText = labelText.trim();
console.log('label text: ' + labelText);
chai.expect(labelText).to.equal(arg1);
callback();
},
function() {
callback.fail('Could not get page label text');
});
When the Assertion is correct there is no problem. However when my labelText is different from arg1 I would like to still keep running it but I don't know how to add the exception or a fail callback in that. At the moment my application just exits. I know that is because I am not using a fail callback (I would like to know where I should have it).
I am also not sure if I should put the callback(); where it is now.
I am looking for solutions online and all I can find are examples using Mocha. I am not using Mocha or Jasmine. I am just using Cucumber framework with protractor. Since Cucumberjs does not have an assertion library, I added chai-as-promised for that. Thanks!
Cucumber.js seems to have issues when expect() calls fail in a callback. Since you have chai-as-promised installed, try doing this:
var labelText = label.getText().then(
function(labelText){
labelText = labelText.trim();
console.log('label text: ' + labelText);
return labelText;
});
chai.expect(labelText).to.eventually.equal(arg1).then(callback);
I got this workaround from this comment and it worked well for me.
If you have chai-as-promised then you can assert async code like this:
this.When(/^I assert async code$/, function(callback) {
expect(asyncMethod()).to.eventually.equal(true).and.notify(callback);
});

Meteor: The application is not spiderable

My application is not spiderable both on local and production.
When I go to http://localhost:3000/?_escaped_fragment_=, I can see the following error appears (phantom is killed after 15 seconds):
spiderable: phantomjs failed: { [Error: Command failed: ] killed: true, code: null, signal: 'SIGTERM' }
It seems that many other people got this problem:
https://github.com/gadicc/meteor-phantomjs/issues/1
https://groups.google.com/forum/#!msg/meteor-talk/Lnm9HFs4MgM/YKDMR80fVecJ
https://groups.google.com/forum/#!topic/meteor-talk/7ZbidddRGo4
The thing is I am not using observatory or select2 and all my publications return a cursor. According to me, the problem comes from the minification. I just read in this thread that someone succeed to display "SyntaxError: Parse error". How can I know more about what is going wrong with Phantom and which file is causing the problem?
This happens when spiderable is waiting for subscriptions that fail to return any data and end up timing out, as mentioned in some of the threads you linked.
Make sure that all of your publish functions are either returning a cursor, a (possibly empty) list of cursors, or sending this.ready().
Meteor APM may be useful in determining which publications aren't returning.
If you want to know more about what is wrong with phatomjs, you might try this code (1):
// Put your URL below, no "?_escaped_fragment_=" necessary
var url = "http://your-url.com/";
var page = require('webpage').create();
page.open(url);
setInterval(function() {
var ready = page.evaluate(function () {
if (typeof Meteor !== 'undefined'
&& typeof(Meteor.status) !== 'undefined'
&& Meteor.status().connected) {
Deps.flush();
return DDP._allSubscriptionsReady();
}
return false;
});
if (ready) {
var out = page.content;
out = out.replace(/<script[^>]+>(.|\n|\r)*?<\/script\s*>/ig, '');
out = out.replace('<meta name=\"fragment\" content=\"!\">', '');
console.log(out);
phantom.exit();
}
}, 100);
For use in local, install phantomjs. Then outside your app, create a file phantomtest.js with the code above. And run phantomjs phantomtest.js
Another thing that maybe you can try is to use UglifyJS to catch some errors in the minified JS file as Payner35 did.
My problem was coming from SSL. You can have a complete overview of what I did here.
Edit the spiderable source and add --ignore-ssl-errors=yes to the phantomjs command line, it will work.

is node.js' console.log asynchronous?

Are console.log/debug/warn/error in node.js asynchrounous? I mean will javascript code execution halt till the stuff is printed on screen or will it print at a later stage?
Also, I am interested in knowing if it is possible for a console.log to NOT display anything if the statement immediately after it crashes node.
Update: Starting with Node 0.6 this post is obsolete, since stdout is synchronous now.
Well let's see what console.log actually does.
First of all it's part of the console module:
exports.log = function() {
process.stdout.write(format.apply(this, arguments) + '\n');
};
So it simply does some formatting and writes to process.stdout, nothing asynchronous so far.
process.stdout is a getter defined on startup which is lazily initialized, I've added some comments to explain things:
.... code here...
process.__defineGetter__('stdout', function() {
if (stdout) return stdout; // only initialize it once
/// many requires here ...
if (binding.isatty(fd)) { // a terminal? great!
stdout = new tty.WriteStream(fd);
} else if (binding.isStdoutBlocking()) { // a file?
stdout = new fs.WriteStream(null, {fd: fd});
} else {
stdout = new net.Stream(fd); // a stream?
// For example: node foo.js > out.txt
stdout.readable = false;
}
return stdout;
});
In case of a TTY and UNIX we end up here, this thing inherits from socket. So all that node bascially does is to push the data on to the socket, then the terminal takes care of the rest.
Let's test it!
var data = '111111111111111111111111111111111111111111111111111';
for(var i = 0, l = 12; i < l; i++) {
data += data; // warning! gets very large, very quick
}
var start = Date.now();
console.log(data);
console.log('wrote %d bytes in %dms', data.length, Date.now() - start);
Result
....a lot of ones....1111111111111111
wrote 208896 bytes in 17ms
real 0m0.969s
user 0m0.068s
sys 0m0.012s
The terminal needs around 1 seconds to print out the sockets content, but node only needs 17 milliseconds to push the data to the terminal.
The same goes for the stream case, and also the file case gets handle asynchronous.
So yes Node.js holds true to its non-blocking promises.
console.warn() and console.error() are blocking. They do not return until the underlying system calls have succeeded.
Yes, it is possible for a program to exit before everything written to stdout has been flushed. process.exit() will terminate node immediately, even if there are still queued writes to stdout. You should use console.warn to avoid this behavior.
My Conclusion , after reading Node.js 10.* docs (Attached below). is that you can use console.log for logging , console.log is synchronous and implemented in low level c .
Although console.log is synchronic, it wont cause a performance issue only if you are not logging huge amount of data.
(The command line example below demonstrate, console.log async and console.error is sync)
Based on Node.js Doc's
The console functions are synchronous when the destination is a terminal or a file (to avoid lost messages in case of premature exit) and asynchronous when it's a pipe (to avoid blocking for long periods of time).
That is, in the following example, stdout is non-blocking while stderr is blocking:
$ node script.js 2> error.log | tee info.log
In daily use, the blocking/non-blocking dichotomy is not something you should worry about unless you > log huge amounts of data.
Hope it helps
Console.log is asynchronous in windows while it is synchronous in linux/mac. To make console.log synchronous in windows write this line at the start of your
code probably in index.js file. Any console.log after this statement will be considered as synchronous by interpreter.
if (process.stdout._handle) process.stdout._handle.setBlocking(true);
You can use this for synchrounous logging:
const fs = require('fs')
fs.writeSync(1, 'Sync logging\n')

Resources