I used to use Cypress 9 on previous projects.
By default, when running cypress open or cypress open --browser chrome used to run all tests for all React components.
However I installed Cypress 10 for the first time on a project that didn't have e2e tests yet. I added test specs, but I don't see any option to run all tests altogether.
It seems I have to run the tests one by one, clicking on each of them.
Can anyone please suggest how do I run all the tests automatically?
It's been removed in Cypress v10, here are the change notes related
During cypress open, the ability to "Run all specs" and "Run filtered specs" has been removed. Please leave feedback around the removal of this feature here. Your feedback will help us make product decisions around the future of this feature.
The feedback page to register your displeasure is here
You can create a "barrel" spec to run multiple imported specs.
I can't vouch for it working the same as v9 "Run all tests", but can't see any reason why not.
// all.spec.cy.js
import './test1.spec.cy.js' // relative paths
import './test2.spec.cy.js'
...
As #Constance says, reinstated in v11.20.
But still a very handy technique if you want to run a pre-defined subset of your tests.
In Cypress version 11.2.0 the Run All button has been reinstated.
You need to set experimentalRunAllSpecs to true in cypress.config.js.
Please see Configuration - End-to-End Testing
If Cypress Test Runner is not a must, I suggest to utilize the CLI/Node Cmd approach
You can trigger all the test(s) by npx cypress run(Still the video recording & screenshot on failed steps would be saved in the respective folders) to run all or with any other cypress flags to filter out specific spec files, or browser etc.
As per the feedback discussion there is a workaround the same as #Fody's answer that will achieve the same result as v9. Also worth noting though is the section on Continuous Integration and the Update 1 that includes a fix for preventing this workaround creating issues with the cypress run command.
Are there any current workarounds?
Yes. If you are impacted by the omission of this feature, it is possible to achieve the same level of parity as 9.x with a workaround Gleb Bahmutov explains here: https://glebbahmutov.com/blog/run-all-specs-cypress-v10/
This will still inherit the same problems as the previous implementation (which is why it was removed) but it will work in certain cases where the previous implementation was not problematic for your use case
https://github.com/cypress-io/cypress/discussions/21628#discussion-4098510
It was removed because people used it wrong.
The Test Runner is for debugging single tests. But by running all tests, then performance will quickly become a problem and crash the entire suite.
Running all tests should only be performed from the CLI.
Sources
https://github.com/cypress-io/cypress/issues/681
https://github.com/cypress-io/cypress/discussions/21628
Related
Is it possible to automatically run unit tests while you work without compiling or running them manually? I am aware that NDepend allows you to do so, but I would prefer to use the ReSharper suite.
This has been available since dotCover 10. See the dotCover documentation for details.
This adds a new panel "Continuous Testing Session" as well as a new status icon in the gutter.
Note that Visual Studio also has this feature, known as Live Unit Testing.
Not possible with Resharper at the moment, you will need something like NCrunch that runs your unit tests continuously in the background, highlighting code that breaks them as you write it and fails your tests.
Edit: At the time of my response it wasn't possible to do this with ReSharper but now in Version 10 it is, see Drew Noakes's answer. You could still give NCrunch a try as it continuously runs your tests in the background even without doing an explicit save.
I've been looking at Jubulas automated functional testing tool and following along with the tutorials, but I've become stuck before I ever even got off the ground with it. The user manual provided with the installation hasn't given any answers and I can't find anything in blogs dedicated to Jubula.
My question: I have my test suite, complete with test cases & steps, all set up and ready to go. I've mapped my objects using the editor. I've started the AUT and connected to it. All I have to do is start the test execution.... I click start.... nothing happens.
The Java application is visible (it's a simple calculator) and I can interact with it. But I don't get any dialogue boxes when I press start, which is what is supposed to happen according to the tutorial.
Has anyone tried Jubula and had this problem?
Two things come to mind.
If the "Start Test Suite" button is disabled, then it means you still have some sort of a problem stopping the Test Suite being executed (e.g. missing data or object mapping).
If the "Start Test Suite" button is enabled, then it might just be that you need to select a Test Suite to execute from the drop-down menu (opened by clicking on the small arrow next to the green button).
I had the same problem but at least I got a report about the tests failing. After I specified the JRE for the AUT (this setting is only shown if you click on the advanced or expert button) my tests finally started to work.
I think it's none of the previous answers. If you get a Failed-test report or your Start Test Suite button is disabled then it's pretty obvious. You can find those mistakes mentioned in documentation/blogs.
BUT! There are two errors which leave no traits; no error messages, nothing in logs.
1.) If there's a version incompatibility If you installed Jubula from a standalone installer or from Eclipse marketplace then it will work. But if you put it together for yourself then you cold mix up the components. I have an answer on these issues:
Jubula doesn´t recognize running AUT after upgrade to 2.0
2.) If you mislead your AUT-agent by starting an other .exe It has exactly the symptoms mentioned in the question. It's happening because the application has the Remote-Control (rc) plugin started in it and the AUT-agent is notified about the start. It tries to identify the process within the AUT-configs listed in the client's (testexec's) database and it misidentifies it.
You can solve this by adding each run-situation as a different AUT-config in your database. It's mostly about location in the filesystem: about where the exec process is launched from. I.e: debug-local (from Eclipse launch-bar), exported-local (for Delta-pack exports), QA-local (if you have PDE in your build) etc.
I am trying to use QUnit with a Meteor app. Should this be possible? Any recommended patterns?
I was trying to make an app that was "self testing" by making a route for "/test" but it doesn't appear that QUnit is running my tests (no test output appears).
#Tom, sure here ya go:
I've added a package for qunit with meteor here:
https://github.com/jpmec/meteor/commit/786b93153d94c0e2291ac210f64587dbbbad23d6
Some facts and disclaimers:
I didn't to the branch right, I branched from master not devel.
I'm not spending much time trying to keep my meteor branch up to date.
This meteor branch is truely fubar'ed wrt the main meteor project, so don't branch from it.
Your best bet is to download, and go look in the packages folder for qunit. That part I think I did right. You'll probably just want to drop this in your meteor packages folder and see if it helps you.
After trying it out some, here are my thoughts to other would-be qunit with meteor users:
I cannot figure out how to easily have a "test site" and "production site" with meteor. It seems like it is all or nothing out of the box, so you can have a self-testing site, but all users get to run the tests. (What I would like is to serve up one site on one port and another site on another port, while maintaining a consistent folder tree for my "app").
The hot-push of meteor is really cool with qunit. As you write your tests you see them go from red to green in semi-real time. No need to keep switching to the test page and refreshing. This is by far the coolest part of meteor, and using qunit with meteor.
The answer to this question was a little more involved for me.
I found no discernible difference between putting qunit in a package, and just including qunit sources in my /client files. My difficulty was that sometimes tests seemed to run, sometimes not at all, and frequently a mysterious "global error" would appear in my test results.
This was called by qunit attempting to automatically launch the test run before my own code had loaded tests. I found no good solution to prevent the automatic behavior. My eventual solution was to let qunit finish its (empty) automatic test run, and then to call Qunit.init(), load tests, then Qunit.start().
I am doing Test Driven Development using the Play Framework and want to keep run the current failing test quickly. I am finding clicking Start! to be to slow since I have a mostly keyboard driven workflow. So ideally I would like a way to just reload the page and have it rerun the currently failing test.
I ended up leaving play test running and reloading the following page - note the auto=yes parameter
http://localhost:9000/#tests?select=Application.test.html&auto=yes
Is there an API for running Visual Studio Unit Tests programmatically?
Running MSTests.exe with Process.Start() does not work in the current scenario. What I'm looking for is something like the NUnit SimpleTestRunner.
Any ideas?
/Erik
You're correct in that there's no public API for the mstest framework. I wrote a manual replacement for mstest one day to see how hard it was, and it's not as simple as it looks (particularly if you want to take advantage of more than one CPU core), so beware of going down this path.
Personally I've always just run mstest.exe programatically and then parsed the resulting .trx XML file. Are there any particular reasons why you can't use Process.Start to run it?
P.S. Some of the strange behaviour of mstest.exe are solved if you pass the /noisolation command line parameter - give that a go if you feel so inclined :-)
Update: Erik mentions he wants to run the test API in the current thread so he can set the thread culture for globalization issues.
If you run a unit test under the debugger, you'll notice that mstest creates a bunch of threads, and runs all your tests in different threads, so this isn't likely to work even if you could access the API.
What I'd suggest doing is this:
From your test "runner" application, set an environment variable
Run mstest pointing it at the specific tests
Add a [ClassInitialize] (or [TestInitialize]) method which reads this environment variable and sets the culture
Profit!
After taking a deep dive with reflector into MSTest.exe and further down into the Visual Studio Unit Test stack, I found that the API used by MSTest is sealed up and made private so that i cannot be used from the outside.
Why not using Reflector and seeing how NUnit SimpleTestRunner is running the tests... And then use this technique...
You can make use of the Microsoft REST API's for TFS to run ms tests. Please refer to the documentation here.
I've linked to "Call a Rest API" so that you can see how you'd go about calling one of the REST API's for TFS.
Note that if your tests are linked to the build, they should run automatically every time a build is queued.
Here is the link to Run Functional Tests.
I've also discovered an article on using the TFS SDK API to run tests. Here is that link as well: Link to API Article