I am working on a nodejs application. The database used is cassandra. We are using https://www.npmjs.com/package/dse-driver.
I am trying to understand how to write tests for the application.
I am specifically confused about how to keep my test database separate from development database.
Can we create and destroy test databases on the fly like Django?
How are test cases for cassandra and nodejs written?
What are the best practices for the same?
You can create a testkeyspace where you initially set up all the tables before each test and drop it afterwards.
If you do so, you should keep in mind, that after truncating tables, there are still snapshots on the filesystem. You probably would want to setup a cleanup job.
Related
I have a database (PostgreSQL) in development environment, which allows me to develop a GraphQL api in NodeJS. I would like to know how to do when I make modifications to the database, pass these modifications to staging and then to production automatically, without having to redo all the queries and so on in each environment.
Do you know how to do it?
Thank you
A typical solution is to use something like migrations. You should have a special table that stores an information about all applied migrations.
The first migration can just execute an initial script that creates all tables, relations, functions and so on.
The subsequent migrations modify structure according to changes in your app and you always know what migrations was applied to a certain DB.
To achieve working with migration you should find a suitable package that can create, execute and undo migrations and maybe seeders as well (something like this package).
I'm using jenkins to automate the testing of my node js application? How do I test the queries to the database? How does Jenkins know to build the mongo db database first? How does automated testing work with database?
I don't use Jenkins for CI, I tend to use TeamCity, but I think your questions can be answered independently of which CI technology you use.
There is no definite answer to your questions, it all depends:
If you are looking to implement full integration tests, including querying a real database, then I would suggest creating a separate database just for testing like - mydb-test. You would have to configure your tests to use this database via config etc. In case you want to isolate your tests from the data access layer, then you need to mock the data access. This can be done by using a mock library, this will be easier to use depending on how well architected is your application code, where dependency injection IMHO is really important on this matter.
I've got a Express web api using sequelize that i want to do end to end testing with. I want to be able to do end to end testing with an in memory database so i can run it on whatever machine pleases me.
I use mysql database for development and production, however i was thinking about using an in-memory sqlite database for testing but i'm not sure what the best way is to get test data into it.
There are several modules around like squelize-fixtures but none of them seem to be able to just fill the database with data without the need to write code around it to manipulate and insert it.
Anyone here doing integration tests with sequelize and sqlite that has figured out a good way of doing it without all the boilerplate code?
If you test this way it won't actually be end-to-end testing since you're using a different database.
However, what is wrong with changing your Sequelize dialect to be sqlite and then using sequelize-fixtures to ingest a file of your data? If you feel this is too onerous you could slog your way through it one time and then just save the sqlite db file for future use. You would then instantiate your Sequelize object with
storage: 'path/to/database.sqlite'
No matter what you do or what storage you choose you're going to have to do some work to seed your database.
I have NodeJS app that uses MongoDB as database. I'm using native mongo driver (not mongoess).
The application allow users to work on projects and share them and the logic that decide which projects a user is allowed to see is built as mongo criteria selector.
In order to test that I've found TingoDB which looks like a great candidate for mocking the MongoDB to be able to run the real model code and check that it is working.
My question is what is the best way to load the initial data? keep it in separate file? Keep it as another model?
Thank you,
Ido.
TingoDB actually stores it's data in flat-files, so if you want, you could just keep a copy of the database in a directory and load that.
However, if you're just testing with a small amount of data, you'd probably be better off keeping the test-data as in your testing scripts, and inserting it through your application as part of the test. That way, you can easily compare the data in the application to the data you loaded in your assertions.
Finally, if you're running MongoDB in production, then you should probably use MongoDB in your tests. While they do have nearly identical APIs, they have very different performance, which should be something you're keeping track of in testing. Unless there's a need to use TingoDB during testing, I'd try to make it as similar to the production environment as possible.
I'm currently building a rest api and I'm struggling to find the best way to unit test each route.
A route handler performs various things and one of them is to execute a query to mongodb. I can unit test the route handler by using stubs, but if I'm testing the query I cannot stub the query itself, I need to have an in-memory mongodb that I could reset and insert new data for each test.
How do you test queries? I'm thinking that the only real way to ensure that the query does what I need is to use a real mongodb database installed in the testing machine (typically in the same machine used for developing).
yes, just as for relation databases, you need to have real base. if mongo offers in-memory auto-created version then it's easy. if not, then each developer has to have running mongo before he runs integration tests. for CI you can have one single dedicated mongo but than you have to prevent concurrent access (schema creation, multiple transactions etc). you should also implement automatic creation of schema if needed and empty database before each test. in relational db rollback is usually enough. when it's not enough then trimming all tables helps. although we had to implement it manually as we couldn't find any existing tools