I'm working on my first test using detox but got the following problem:
Please help me.
Unfortunately, being a wrapper over common JS test-runners such as Mocha and Jest, when Detox fails to initialize in (i.e. in the beforeAll()) it is forced to move forward to nevertheless try to run all tests in the suite. Also, without proper initializaion, global objects such as by, device and even detox do net get registered. Hence the error.
What matters in your case is for you to scroll and find the first error provided by Detox' logs. That should give you a hint of what really went wrong.
In any case, your tests will not run without proper initialization, and the inclusion of init code in the path for the test runner. Be sure to thoroughly go over the setup guide and its references.
Related
I wanted to try automated testing with Vue3 for my next project.
When I created my app using Vite and selected that I would like to test with Cypress everything seems to work fine but...
Although project starts like it suppose to when i type in console npm run lint I receive an error message saying:
C:\Users\myname\Desktop\vue-project\cypress\support\component.js
27:1 error 'Cypress' is not defined no-undef
and this is the line in which error occurs:
Cypress.Commands.add("mount", mount);
Any help from you guys would be appreciated
Ok so maybe someone will find it helpful.
It appears that problem with this one considers mainly ESlint.
If you can not run Cypress with command npm run test:unit:
make sure Cypress is also installed globally.
Then simply ignore ESlint errors considering cypress and don't change this line - const { defineConfig } = require("cypress"); even if lint suggest
doing it.
Congrats, you now should be able to run tests with Cypress :)
Bonus: if you do mind errors in your console and wanna keep it clean you search for some lint setup considering Cypress, to find a good setup for your lint if you do mind errors in your console.'eslint-plugin-cypress' didn't do the trick for me.
I am currently using Nightwatch to test a site running on an MVC controller. All other Nightwatch commands and assertions are working, but when I try to use Expect assertions I get an error:
.expect.element(...).to.be.present is not a function
The element is definitely on the dom and I have the
I have tried requiring chai-nightwatch in my globals file generally and by specifically assigning it to expect, but they continue to error out when I run the test.
client.expect.element().to.be.present WORKS
I am trying to implement raygun for a react-native app. I am running into problems with jest and I am not sure of the best approach given the window does not exist. In my package.json I have already added the following:
"globals": {
"window": {}
}
I get the following error though and I am unable to resolve it as of yet:
ReferenceError: raygunUtilityFactory is not defined
This is a very basic implementation as per the docs:
https://raygun.com/docs/languages/javascript#reactnative
I presume this is something with jest but having searched on github, here and google I still have not been able to resolve this.
Raygun4JS does not currently work correctly in a non-browser environment. Your best bet would be to not include the Raygun4JS code inside of your test environment (which is what we do at Raygun) but that is a bit more complicated using the UMD module from NPM (we use the snippet approach to inject it dynamically).
I think the problem stems from window not being considered the global object in Jest vs the browser, we have an indirect call to the window object to call the raygunUtilityFactory. Are you using the jsdom test environment? We also have the same window definition in our jestconfig.json and export some variables onto window in our setupframework.js file that are accessed indirectly through the global object and it appears to work correctly.
I’m writing tests for an Ember.js application with Mocha. I use the ember-mocha-adapter from Teddy Zeenny.
As soon as a promise is involved, the tests fail randomly. I usually get this error:
Error: Assertion Failed: You cannot defer readiness since the `ready()` hook has already been called.
Here is a JS Bin testcase. It contains 10 times the same test and usually fails (tested with Firefox and Chromium).
The same tests run fine with QUnit (maybe by chance :)) (JS Bin testcase). How can I make this work with Mocha? I tried wrapping the promise in an Ember.run() call, but it doesn’t solve the problem.
There is another question about the same problem, but the corrected JS Bin proposed by Teddy Zeenny also fails for me.
There are 3 problems with the code:
It should not call mocha.setup(), as is now explained in the README.
The function calls to setup Ember.js for testing should happen outside any Mocha callback, not in before().
mocha.run() should be called like this:
Ember.$(function() {
mocha.run();
});
Here is the fixed JS Bin testcase.
Teddy Zeenny found the solution to this problem in teddyzeenny/ember-mocha-adapter#18.
Really the only reason the qunit is working and mocha isn't is because you're running reset before each test vs after each test.
http://emberjs.jsbin.com/nusewoqi/4/edit
i have a problem to run test. My model use extension Yii mail and then i run test its fail with wrong assert path. Another test runs finaly (model dont use any extensions). Preloading is only log.
I had a similar error and I explicitly set the basePath in config/test.php.
'components'=>array(
...
'assetManager'=>array(
'basePath'=>dirname(__FILE__).'/../../assets',
)
)
Im solved problem
public function setUp(){
Yii::app()->assetManager->basePath = '../../asserts';
}
Im dont know why this error throw only in one model...
PhpUnit runs primary in CLI mode and therefore some of environmental variables are missing. Yii's AssetManager uses one of such variable to determine webroot and since the variable does not exist, it will either throw error or set up invalid assets path on first attempt.
In my opinion, this issue is (indirectly) caused by PHPUnit because it only supports CLI testing mode, which makes some things really more difficult to test than it would be in HTTP request mode. Some guys therefore wrote tools to run unit tests via standard web GUI with whole native HTTP environment (e.g. https://github.com/NSinopoli/VisualPHPUnit). Eventually, you may use HTTP clients like Selenium to run your tests as if clicking over the page (see http://phpunit.de/manual/3.7/en/selenium.html).
Nevertheless, it's a matter of subjective opinion - somebody may argue, that testing in CLI mode has advantages, some guys will hate it. But the fact is, that one has to bear in mind differences between HTTP and CLI mode.