I have a simple REST API written in Node.js, Express, and Prisma. I would like to write both unit and integration tests in Jest, where unit tests rely on a mocked Prisma client and integration tests run against a real test database.
I followed Prisma's guide to unit testing, which works well so far. However, running integration tests isn't possible because the Prisma client is mocked.
The jest.config.js uses setupFilesAfterEnv to boostrap the Prisma mock.
My test files are co-located with the actual source code, not within a dedicated directory.
All tests (unit and integration) are launched via jest --watch.
I would like to know a good strategy to run some tests with the mocked Prisma client and some tests with the real one. So far, my ideas didn't work out (like conditionally mocking Prisma or calling jest.restoreAllMocks()). Do you have any suggestions/ideas how this can be achieved?
Related
I started a project and have about 7 tests in my project now and it takes already more than a minute to execute the whole test suite using gradle test.
From the additional output (--info flag) I can see that the whole quarkus application and also dependencies like the mongodb instance are restarted for every test class and method.
This is the exact opposite of what the quarkus documentation says on the testing guide page:
So far in all our examples we only start Quarkus once for all tests. Before the first test is run Quarkus will boot, then all tests will run, then Quarkus will shutdown at the end. This makes for a very fast testing experience however it is a bit limited as you can’t test different configurations.
All the tests are annotated with #QuarkusTest and every test just tests a single endpoint.
I use "pure" kotlin (1.5.21), Quarkus version 2.2.2.Final and gradle 6.9.
Installed features: cdi, config-yaml, jacoco, kotlin, mongodb-client, mongodb-panache-kotlin, narayana-jta, rest-client, rest-client-jackson, resteasy, resteasy-jackson, smallrye-context-propagation, smallrye-health, smallrye-openapi, swagger-ui
Is that a normal behaviour? If yes, an application with multiple hundred tests could easily take ~20 minutes or more to run the entire test suite.
I didn't try out maven yet, so I can't verify that it's not a gradle related issue.
While trying to reproduce it with a fresh project, I think I found the issue with my code:
I also used #QuarkusTestResources with restrictToAnnotatedClass=true on my tests.
This means the configuration & test profiles must be reloaded and therefore also the quarkus application.
Apparently all the DevServices get restarted, too (in my case it was a mongodb, since I'm using the panache extension), which explains the long runtimes of the tests.
I reorganized my tests a little bit, so they work with the "global" test resources (it was a WireMockServer in my case).
Now quarkus only gets started once before the tests and the total runtime of the gradle test task is acceptable.
We are building a shop for a customer on Shopware 6.3.5.2 and want to use tests to
ensure that core functionality is not broken by our customizations (static plugins)
write new tests for new functionality
There is Running End-to-End Tests but this seems to be for core development and uses psh.phar which is not available in the production template.
How should this be done?
edit
This question is meant a bit broader and concerns also Unit Tests.
Actually, you can use the E2E tests of the platform project - as Cypress itself doesn't care where to run the test against. However, as you already noticed you cannot use psh commands to run them. You may run the tests though the basic Cypress commands, setting your shop's url as baseUrl of the tests, for example via this command:
./node_modules/.bin/cypress run --config baseUrl="<your-url>"
It works with cypress open as well.
The only thing what may become troublesome is the setToInitialState command in most of the tests which takes care about the clean up of shopware's database using psh scripts, unfortunately. You may need to adjust it by overriding the command in order to reset the database of the Production template.
I hope I was able to help a bit. 🙏
There are actually two parts here:
ensure that core functionality is not broken by our customizations (static plugins)
write new tests for new functionality
re 1: For regression tests like this I would suggest end-to-end tests. Either test through the UI with tools like selenium or through the HTTP API (I don't know if the shopware API is sufficient for extensive regression tests).
re 2: Since plugins do not run on their own I would extract all relevant functionality into plain old PHP classes that are independent of shopware and test those in isolation. Explore if some of that functionality can be made visible through an API and test the plugin integration through this. Depending on the actual plugin you might have to resort to UI tests again.
I am to build a test automation system for E2E testing for a company. The product is React/Node.JS based runs in a cloud (Docker & Kubernetes). The code is stored in GitLab repositories for which there are CI/CD pipelines setup for test/lint/deployment.
I plan to use Jest for test orchestration and Selenium / Appium for the UI testing (FRW being in TypeScript), while creating a generator to test our proprietary backend interface.
My code is in a similar repository and will be containerized and uploaded to the test environment.
In my former workplaces we used TeamCity and similar tools to manage test sessions but I do not seem to be able to find the perfect link between our already set up GitLab CI/CD and the E2E testing framework.
I know it could be implemented as part of the pipeline, but for me it seems lacking (which can also be because of my inexperience)
Could you advise some tools/methods for handling test session management for system testing in such an environment?
(with a GUI where I can see the progress of all sessions, being able to manage them, run / rerun / run on certain platforms only, etc)
I want to automate unit test cases for SPFX using Jest Framework. I am able to write the test cases but do not know how to get SharePoint context in jest text cases to get properties from SharePoint. Any pointer will be of great help. TIA
I come from a configuration management background using tools like chef. I have done quite a bit of code testing. Recently, I have been entrusted with the responsibility to work on the CI-CD of the various applications. But I am noticing a culture that’s quite not in line with my ideology.
Let’s say we have 4 environments in the CI-CD pipeline: Dev, Test, Stage & Prod. The dev environment is used by the developers to deploy and test the app before rolling out to the next stage (test). The test env is for the QA team to run their test. And STAGE is another env for 2nd layer of test by the QA folks before the code goes to prod.
Now, does it make sense for the QA or the CI process to run unit test while progressing/after deploying the code to (TEST or STAGE)? I agree that the unit test should be a part of the automated build. But unit test is mainly for the developers, for their code testing. The QA should be focus on the functional testing, load testing etc.. using their frameworks which may be selenium/protractor or LISA. Why should they be focusing on junit or nunits?
From my experience the developers do the unit testing.
Where I currently work, we follow TDD (Test Driven Development) so developers write the unit tests for their code first and then they write the actual implementation. This work goes on the Dev environment.
The QA people then do the acceptance tests and review stuff.
I hope this helps.
Unit tests are short code fragments created by programmers or occasionally by white box testers during the development process. Unit tests are typically written and run by software developers to ensure that code meets its design and behaves as intended.
Hope you got the answer.
Your concern is absolutely right. QA does not necessarily be doing Unit Testing (If that's what you mean). This testing is done by dev while they were writing the code (if they were in TDD environment or even if in BDD).
However if QA has used Junit to write their Selenium automated test cases then they will be using Junit to update and change their automated test cases.
It's little difficult to automate Selenium test cases using Junit whereas using other framework like TestNG is the best option to write automation test cases for Selenium.
I hope this answer your question.