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
Related
Recently I ran into a problem that it seems no one know how to solve.
I want to run async code (#1) when I ...
start dev ( i.e. npm run dev or npm run serve )
before compiling
That means, the async code can only run once!
And I can't use the feature of of "Service Plugin" (#2) in Vue Cli to do that.
Because it's async, I even can't use any webpack hook list here (#3)
BUT!
I knew that can be achieved by using Vite (#4)
I just out of idea how to do that in Vue CLI (after spent tons of hours)
Any expert have an idea?
Note
#1 This should be not important at all, because it's an implementation details, but I'll just leave it here: The async task for me is starting a local websocket server.
#2 Because you can write down async code in Service Plugin, for more info, check this
#3 You might see a webpack compiler hook called beforeRun can support async, but sorry, that also doesn't work for me.
#4 As shown here, you can see there's a method called configResolved, which can let you do async task, and achieve what I want as I described in this post. I'm not considering to choose Vite for just solving this problem, because this would be too overkill.
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.
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
The Durandal Test Framework runs Jasmine tests within PhantomJS.
Where I'm implementing this for the first time I'm getting a lot of errors, and reading through these on the command prompt is proving to be very tedious.
If I load up the spec.html file in my web browser, it tells me that no specs were found:
Yet PhantomJS is able to find the specs with no problem:
Is there a way I can configure these Jasmine tests to run through my web browser and not through (or as well as) PhantomJS?
I've set up a new index.html file and have replaced the var runTests = ... section with a simple require() call:
require(['../test/specs/system.spec.js']);
Durandal's system.spec.js file is loaded in the browser, but Jasmine is still stating that no specs were found.
Jasmine's tests weren't being run because I wasn't telling it to re-execute. The solution to this was to simply re-execute by calling this within the require callback:
require(['../test/specs/system.spec.js'], function() {
jasmine.getEnv().execute();
});
Note: A drawback of this is that the 'no specs found' bar is still present and the 'raise exceptions' control on the re-executed specs doesn't appear to function:
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.