The release notes for Jest 24 highlighted a new feature that I want to make use of: test.todo. However, for the life of my I am unable to use it.
For example, I want to sketch out tests in my subscriptions.test.ts file so I create the following:
describe('Subscription Tests', () => {
test.todo('... a name');
});
The TypeScript compiler then promptly presents me with a red line under todo saying, Property 'todo' does not exist on type 'It'.
I am sure I am missing something obvious but I've hit the wall at this point. Can someone help?
Thanks to the comment from #jonrsharpe I ran yarn upgrade #types/jest --latest and that resolved my problem. Urgh -- could not see the wood for the trees!
I feel pretty dumb for a while because my test was failing after adding the todo(). I shoud've read the documentation more thoroughly. Here is my problematic code:
test("should show progress indicator when authorizing", () => {
test.todo("should show progress indicator when authorizing")
})
But it need to be like the below. Passing callback when using todo and nested test() in the callback are not allowed.
test.todo("should show progress indicator when authorizing")
Related
I need to skip all it() if beforeAll() failed, but all solutions that I found don't work - beforeAll() throw an error but all of it() still executes and gets marked as 'failed'
I've tried:stopSpecOnExpectationFailure: true, and Jasmine pending() option but those still do not work.
Does this solution fits your needs?
https://www.npmjs.com/package/protractor-fail-fast
or
https://github.com/pmowrer/jasmine-fail-fast
I know that suggest npm-packages is not a real 'answer' but I've been seeing this type of questions every couple of months and it usually ends up with using some ready and working solution (like above)
Update: I will appreciate if you will come up with your own solution and share it
Update 2: Also I will share one wacky way you can do it.
You will need Protractor 6 (because it uses latest jasmine version)
Let's say you tests are depending on the presences of some element.
You can do this in your beforeAll :
let elementIsPresent = await myElement.isDisplayed()
it('should test if element is present', function() {
if(elementIsPresent) {
// do your thing
} else {
pending('skipping test')
}
});
You need to be aware of a couple of thing:
Protractor below version 6 will mark this test as 'failed' (instead skipping)
I can not use arrow functions in your it blocks
My AngularJS (1.7.x) application has a custom filter that I want to write tests around it, and I decided to use Jest to perform this task.
My main issue is that as I follow this tutorial by Curt, I am struggling to properly get the filter (which has no outside dependencies so I thought it was the prime target to introduce unit tests with) to load within the test harness.
For starters, here is a simplified version of the filter for the purpose of this question:
angular.module('app.module').filter('takeTheThing', () =>
function (parameter1) {
return `${parameter1} thing!`;
}
);
And, after following the tutorial above, as well as reading up on another SO question specific to testing AngularJS filters, I have attempted every conceivable version of my simple test file as follows but receive a cryptic error message from Angular about it:
require('../node_modules/angular/angular.min.js');
require('../node_modules/angular-mocks/angular-mocks.js');
//Commenting or un-commenting this, results in module-related injector errors:
//require('./takeTheThing.filter.js');
describe('The thingerizer', () => {
let $filter;
beforeEach(angular.mock.module('app.module'));
//Injecting this specifically, or _$filter_ still errors:
beforeEach(inject(takeTheThingFilter => {
$filter = takeTheThingFilter;
}));
//Injecting here instead of in the beforeEach, same issue
it('should give me something', () => {
//Calling the specific filter or thru the Angular $filter... Same
const actual = $filter(1);
expect(actual).toEqual('1 thing!');
});
});
I'm pulling my hair out, but there's something quite basic I'm missing in regards to the test setup (specifically, how to load the app "correctly" without whole-hog loading my entire application). What gives?
AngularJS: 1.7.5
Angular Mocks: 1.7.6
Jest: 23.6.0 (I am using gulp-jest but even when I directly call jest from within the bin folder, I get the exact same errors, so I omitted most of those details here)
I have the following test.js file:
const test = require("ava");
test.before("foo", t => {
someSetupThatMightThrow();
});
test("bar", t => {
t.pass();
});
test.after("baz", t => {
someTeardownThatMightThrow();
});
After running ava --verbose, if any of the hooks throw, I get a red X in the test report, which is great. But if nothing throws, I get only one green checkmark for the bar test:
I would like to see green checkmarks relative to the before/after hooks as well, instead of them simply being omitted. How can I do this?
We won't output those in our regular reporters, sorry. I'd say don't worry: the hooks will run.
(Eventually down the line maybe we'd have a much more low-level reporter which would include this information, that you could build your own reporter on, but that's a ways away.)
I have a test which contains steps that I'll want to reuse in multiple files.
I'm thinking I could create a file called common.js, list all the functions in there and just call as and when I need.
Is this a recommended approach?
The only issue I feel is having a super long file of common methods and if i seperate then I'd need to use lots of require statements.
The simplest would be to do what you have hinted to make a commonSpec.js file and use it anywhere by importTest() which would be something like this :
commonSpec.js
describe('Common Steps that will be used by all', () => {
it('Can log in', () => {
//log in code
});
it('land on a particular page', () => {
// assertion code for the particular page
});
});
commonSpecUsed.js
describe("Common Specs", () => {
importTest("common specs", './commonSpec.js');
});
The above approach is best and simple when they share the same specs and assert the same values. But when the assertions are different for e.g
A normal user will land on a simple user page
Registered user will land on their "my account" page
Admin will land on their dashboard page ..etc..etc..
Then you might want to make your commonSpec.js file more dynamic by enabling it to accept parameters. This would be entirely based on your test requirements. Can be more helpful if you could please share some code snippet.
Hope this helps.
One option is to set up Page Objects, as defined in the official docs. I also have a video covering subject on YouTube.
If you don't want to do page objects, you can add custom commands to WebdriverIO using the 'addCommand' command.
Node has a class, EventEmitter, that is a pretty common fixture of node.js and electron programming. Unfortunately it's a PITA to debug. Imagine some code like this
import EventEmitter from `events`;
const emitter = new EventEmitter();
emitter.on('foobar', handleFoobar);
emitter.emit('foobar', 'foo', 'bar');
function handleFoobar(..args) {
console.log(...args);
}
Now I want to step through the code in the debugger. Of course in this small example I can put a breakpoint on handleFoobar but, in real code I just want to be able to step through the code, when I get to someEmitter.emit I want to be able to pick something along the lines of "Step Into Listeners".
Unfortunately no such feature exists AFAIK. The implementation of EventEmitter is fairly complex so stepping in to see get to the listeners requires stepping about 20-25 times. You can set breakpoints at all the exit points but there are at least 6 of them which is also annoying when you want to turn them all on/off.
Are there any other creative solutions to effectively implement something like "Step Into Listeners" when on a someEmitter.emit line?
One solution comes to mind which is to replace events.js with a simpler implementation. Without domain support and using ES6 features it could be much smaller implementation like
EventEmitter.prototype.emit(type, ...args) {
const listeners = this._listeners[type].slice();
listeners.forEach(listener => {
listener(...args);
}
return listeners > 0;
}
I suppose I could also patch that into the prototype if process.env.NODE_ENV === 'development'
Are there any other more generic solutions? Like maybe a debugger feature where I can pick code to never step into directly but picking step into in the debugger comes out of its exit points?
I found the solution. It's called blackblocking
You can set by script filenames which files not to step into so, adding events.js to the list does exactly what I want. When I'm on the someEmitter.emit and I press "Step Into" I come out the listeners immediately!