When I populate the database, I don't do it completely (for certain tests I chose to populate only when I get to them). In the end, I would like to reset the database, so that when I do the next populate (the next tests running), the database will be reset so that complications do not appear. How could I reset this database after running all tests (all specs)?
What I tried to do was to use the "after" hook with the "npx prisma migrate reset --force" command, but that resets the database after each file, not after all the specs have run.
One option would be to make a file in which to import all the test files, and when I run the file with all the imports, in the end, reset the database. The minus in this version is that every time I add a new test I have to include it in the imports from this file.
What would be the best practice?
If you have something that works in the after() hook, try moving it to the After Run API which is kind-of a hook, but as it says executes after the run.
Here's the basic shell from the docs:
const { defineConfig } = require('cypress')
module.exports = defineConfig({
// setupNodeEvents can be defined in either
// the e2e or component configuration
e2e: {
setupNodeEvents(on, config) {
on('after:run', (results) => {
/* ... */
})
}
}
})
One thing you should do after implementing is deliberately fail a test and see if the database is cleared. Some after() type hooks don't run in a fail scenario.
If you find that to be the case, instead add a before() at the top of the cypress/support/e2e.js file so that the database is cleared before each run.
Also, importing your setup functions there can save you importing them into each spec.
Related
I am writing a test kit on cypress for my web application. One thing I want to be able to do is display certain data about the state of the application appended to each test so I know the particulars of that user's configuration. For example, the url of the test, whether the user has certain permissions or not etc. I am using mochawesome for the reporting but am not entirely partial to it. Is there some way to add data that comes from cy.get, cy.find... commands to the reporting?
I figured it out. Add this to support/commands.js
import addContext from 'mochawesome/addContext';
Cypress.Commands.add('addContext', (context) => {
cy.once('test:after:run', (test) => addContext({ test }, context));
});
Then use the function through cy.addContext("whatever").
It will get added to the mochawesome test file.
I am very new to the strapi, and I am looking for the best way to create an import job for it.
This job is supposed to be run as a cron and get its data from a temporary database, which means no uploaded files etc.
Strapi is deployed as a docker container to the kubernetes.
There is an example of importer plugin, but it is too huger for has unnecessary frontend while I am looking for something lighter.
You can use strapi controller e.g Restaurant is a controller
call it in browser like
localhost/restaurant/import
module.exports = {
import: async (ctx) => {
// getRecord(// code goes here)
// strapi.services.restaurant.create(passData)
}}
1 - get data e.g from api https://www.example.com/wp-json/wp/v2/
2 - create strapi record strapi.services.restaurant.create()
You can call localhost/restaurant/import using cron
I'm trying to assign a variable from one test to be accessed within another test. For example:
let user;
test('create new user', async () => {
const response = await createUser()
user = response
})
test('delete user', async () => {
const response = await deleteUser(user.id)
})
I understand that jest has a --runInBand option, however this still has user as undefined in "delete user". Any ideas how to accomplish this with jest? Thank you
Each test runs independently, and for good reason. Tests should be confirming isolated conditions, methods, and logic. All --runInBand does is run the tests in serially, but they still won't necessarily be able to share data objects the way you seem to be expecting.
Also, assuming these methods defer to a backend service of some kind, you're not going to easily be able to fully test the behavior of that system. It sounds like you want an end-to-end or integration testing framework, as opposed to a unit testing framework like Jest.
Keeping with Jest, you're likely going to need to mock whatever backend service is being called in createUser and deleteUser. Jest mocks can help replace external functions with new ones that create the types of conditions you want to test.
Alternatively or in addition, you might be able to stub your user object using beforeAll or beforeEach, creating sample data that allows you to test how deleteUser behaves when it's passed a particular object (likely bypassing whatever backend persistence with an aforementioned mock).
I have a react app with redux state which is stored in localStorage
The problem is that data structure has changed and some older users get an error. Need a reset.
If I add localStorage.clear() to the code, it will run every time and there will be no point of using storage it at all.
Is it possible to reset localStorage only once with kind of specific flag passed with deploy? Something like css files which have versions, i.e. .css?412uisqfh9-wq different for deploys
You can run localStorage.clear() only once.
What you need to do like below:
if (localStorage.getItem("clearStorage") === "<old version number>") {
localStorage.clear();
localStorage.setItem("clearStorage", "<new version number>");
}
In first run only if condition code will execute and after that everytime this condition will be false and will never execute.
So I created a new Sails.js project, then ran
$ sails generate api user
like the loading page suggested. But now when I fire up the server with sails lift I get an error:
sails lift
info: Starting app...
-----------------------------------------------------------------
Excuse my interruption, but it looks like this app
does not have a project-wide "migrate" setting configured yet.
(perhaps this is the first time you're lifting it with models?)
In short, this setting controls whether/how Sails will attempt to automatically
rebuild the tables/collections/sets/etc. in your database schema.
You can read more about the "migrate" setting here:
http://sailsjs.org/#/documentation/concepts/ORM/model-settings.html?q=migrate
In a production environment (NODE_ENV==="production") Sails always uses
migrate:"safe" to protect inadvertent deletion of your data.
However during development, you have a few other options for convenience:
1. safe - never auto-migrate my database(s). I will do it myself (by hand)
2. alter - auto-migrate, but attempt to keep my existing data (experimental)
3. drop - wipe/drop ALL my data and rebuild models every time I lift Sails
What would you like Sails to do?
info: To skip this prompt in the future, set `sails.config.models.migrate`.
info: (conventionally, this is done in `config/models.js`)
Is there a sails migrate command I have to run? I know in rails I would do something like rake db:migrate. What's the procedure in sails after the generate command?
It's not an error, it just tells you that you did not specify a default migration strategy.
Just open config/models.js
and uncomment the line where it says migrate like in the picture above.
Like the information "popup" tells you, you can choose between
safe
alter
drop
Drop will delete all your tables and recreate them, which is good for a new project and you want to seed new dummy data all the time.
Alter will try to keep your data but will make changes to your tables if you do so in your models. If sails can't keep the data, it will be deleted.
Safe is, like the name says, the safest. It will do just nothing to your tables.
If you want to take different action for different tables, you can specify just the same options within your model directly which will overwrite the default setting for this model only.
So say you have a User model and want to keep that data but want to have all other models recreated everytime you sails lift, you should add
migrate: 'safe'
to the model directly and use drop as default strategy.
I like alter personally, but that might be opinionated.
You do not need to make anything else. If there's a model and migrate is set to drop or alter, it will be migrated when sails lift is run.
You can read more about model settings here
As a sidenote, you can see what sails is doing exactly to your tables during lift by setting
log: 'verbose'
in your config/env/development.js file: