I am using TypeScript, and I have the following definition:
const contentElement = document.getElementById("contentId")!;
Where I know for sure the relevant element is defined in the HTML file with contendId.
I have ran eslint, and I get the following error:
Forbidden non-null assertion.
So... What would be the proper way to handle this case? Tending to simply add a suppress warning, as the other options would simply just increase complexity. But maybe I am overlooking a simple solution here, other than adding:
// eslint-disable-next-line #typescript-eslint/no-non-null-assertion
Forbidden non-null assertion. is just a lint warning/error because your value can be nullable. If you are sure of the value then you can cast it to the expected type like below
const contentElement = document.getElementById("contentId") as HTMLElement
Related
Is there a difference between
expect(screen.queryByText('<something>')).toBeInTheDocument();
And
screen.getByText('<something>');
(The specific getBy* and queryBy* operation are not relevant)
In react-testing-library?
getByText tries to find the node and throws an error when it is not able to find it. This will cause the test to fail immediately.
queryByText on the other hand will return null if it is unable to find the node.
Let's suppose you have text <something> in the component that was rendered, you can assert if it has been rendered or not.
If sure that the text has been rendered, then you can simply use getByText
expect(screen.getByText('<something>')).toBeInTheDocument();
and the test would pass.
If for the scenario the text did not render then the above assertion will thrown an error and fail the test case.
In such cases queryByText text makes the most sense
When has not been rendered
expect(screen.getByText('<something>')).not.toBeInTheDocument(); // throws an error
expect(screen.queryByText('<something>')).not.toBeInTheDocument(); // asserts as true
Output comparison
I'm using Acorn to parse some syntactically valid JavaScript code into an ESTree for further processing. It appears that Acorn does some semantic checks too - in particular it throws an error for duplicate declarations. For example, parsing the following code throws an error of Identifier 'f' has already been declared:
function f() { return 1; }
function f() { return 2; }
I do not want such semantic errors to be checked - I'm doing custom processing on the resultant ESTree, so the semantic validity of the source code does not matter to me.
I've looked though the Acorn options for the parse(input, options) function, but I could not find anything that sounds like what I want.
Is there a way to disable such semantic checking?
It seems like there is no proper way to disable semantic validation. I managed to get what I want with an ugly hack, by overriding the raiseRecoverable method.
This worked for me (note that I'm using TypeScript here, but it would of course be possible to do the same in plain JavaScript):
import { Parser } from "acorn";
class SyntacticParser extends Parser {
raiseRecoverable(pos: any, message: string) {
if (message.includes("Identifier ") && message.includes(" has already been declared")) return;
(Parser.prototype as any).raiseRecoverable.call(this, pos, message); // weird call syntax required because the TypeScript types for Parser doesn't contain the `raiseRecoverable` method
}
}
It's an ugly hack because I'm filtering out the duplicate declaration message based on the stringified error message. However, there does not appear to be a better way.
I was originally using the mocha command line tool to run my tests and they were working fine. I switched to using the wdio command to run my tests. My tests now throw an error with this line of code:
browser.waitForEnabled('#div_id');
With this error:
Promise was rejected with the following reason: Error: selector needs to be typeof `string`
running chrome
Error: Promise was rejected with the following reason: Error: selector needs to be typeof `string`
at elements() - isEnabled.js:18:17
at isEnabled() - waitForEnabled.js:37:22
This was working fine until I started using wdio (specifically I run wdio --spec path/to/file.js). I've run the typeof function on the selector in question and verified that it is, in fact, a string.
The div in question looks like this:
<div class="highlight" id="div_id">
A fair bit of content goes here.
</div>
Why am I seeing this error? How do I fix it?
waitForEnabled() documentation => http://webdriver.io/api/utility/waitForEnabled.html
wdio documentation => http://webdriver.io/guide/testrunner/gettingstarted.html
Update:
I've tried adding a timeout to the waitForEnabled() function. Since I've done so, it sometimes fails, and sometimes does not. More often it fails though.
I'm not marking this as the answer because I have no idea why it works. But passing in all of the optional params to waitForEnabled() makes it work just fine.
As in:
waitForEnabled('#div_id'); Fails. Wheras:
waitForEnabled('#div_id', 99999, false); works without errors.
The fact that you're passing milliseconds & the false option should not make the test pass.
I'd suggest using some of the other waitFor commands, like waitForVisible() or waitForExist(), because I'm assuming this is what you really want from the code example you gave above. The waitForEnabled() command waits for a field that had a disabled html attribute, to not have it anymore. You can read more on that here: https://www.w3schools.com/tags/att_disabled.asp.
Sometimes, when you type enter after a correct finished statement, the REPL waits for more :
> var f; function(){};
...
When exactly does that happen ? I didn't found any documentation on that.
Your code is not correct. When run from a file, a syntax error is reported:
SyntaxError: Unexpected token (
There was a bug in REPL where in the case of a syntax error, REPL assumed the code to evaluate is not complete and would span multiple lines. Regardless of the type of syntax error.
The issue was fixed in v0.11.7 by commit 9ef9a9d. See the commit message for more details.
In the current Chrome, if I do this:
var i = 'foo';
i();
I get an error 'string is not a function'. I get similar errors if i is a number, undefined, etc.
However, from some real-life, more complex code, sometimes I see a different error:
'expected function: function(){}'
I am trying to figure out exactly how these two errors differ, or, to look at it another way, how to write a minimal code snip that will trigger the 'expected function' error.
I tried fiddling with callbacks, and call/apply, but none of those trigger this. Can anyone explain how to reproduce this error?
There is no specification what error message should be. Therefore each vendor implements it's own. The only way to unify this is to verify data yourslef and throw error that you expect.
var i = 'foo';
if (!$.isFunction(i)){
throw 'expected function: function(){}';
}