I am writing a Node.js application that acts as GraphQL server. And I want to test if GraphQL is giving me the right results.
My guess is to make a request to server in each test and then watch if it is right or not. But I'm not sure how to set it up, how to run the server and clean the database before all tests and shutting it down after all tests are finished.
I worked with rspec using Ruby on Rails before, so I want to do something like rspec does in Node.js. Is there a way to accomplish it using Jest? And if not, how can I do something simular?
This isn't really an Jest specific question but more how to perform integration testing in Node.
The fact you're using Jest makes very little difference other than you'll want to ensure auto mocking is turned off.
Normally when writing integration style tests I'd use something like supertest to make requests and setup the database to use sqlLite or similar running a seed.
I'd recommend looking for similar tools like graphql-tester.
Related
I want to set up a CI/CD workflow which includes testing my server as a whole.
Using node I have a couple options such as
Jest,
Mocha,
Chai
or a different approach such as Postman/Newman.
I have tried out Jest and found it very difficult to adjust my databases such as Postgres and Redis to the mock environment. In fact, I didn't get it to work at all, presumably because of all the technologies involved.
Is there is a tool, maybe one of the others mentioned, that takes the server as it is, without any additional configuration, calls the endpoints of the Server and gives me results, which I can then use to further take action (push/rollback/discard changes)?
I have a question regarding the different tests for a node and specifically an express application.
I am new to node/express coming from a PHP background, so have a few questions.
I know about unit testing, using things like PHPUnit, so I have read about about Jest. My specific questions regarding jest and unit testing in an application like express. Is should I be breaking my code apart more? It currently is quite together my routes are basically where all my business logic is found. Which means it's difficult to unit test?
Then with something else like end to end testing, I am looking at testcafe. For this I am really unsure how to get past my authentication and furthermore how to test on my local machine, before pushing code to production.
Full disclosure, I have a CI setup to my main branch, so I am looking to implement these tests to stop me merging breaking code to my master branch and breaking the production site.
Personally I always prefer mocha.js for testing any node app. It specifies how many test cases are passing, generates a report for those which are not passing. Also it specifies the time required to execute a code segment.
I'm also relatively new to node. I use the same stack as you (Express + MongoDB), applying MVC pattern. In Java I used to write a lot of unit tests with Spock, but right now I focus mostly on integration testing.
In my opinion routes should not contain any logic. Try to move it to separate layer - services. This way you can focus on testing logic provided by them, instead of trying to test code hidden in your routes.
For testing I use mocha.js, chai and chai-http.
My approach is to set up test database and form my tests as a sequence of requests. There is no problem with testing authentication that way - just need to correctly set up db with some user data. If you want to cut off the dependencies like database, use sinon for stubbing and mocking.
The obvious downside of this approach is testing time, but you can split tests into unit and integration suites. Run your unit tests locally and integration tests in your CI pipelines.
I'm not sure if it's the best approach, but I'm positive about the effects. Learning new technology means refactoring a lot. I have changed the structure of my project multiple times, moving logic, extracting methods and classes etc. Integration tests assure me that I haven't broken the business logic, despite having changed what's in the black box. This kind of breaking changes would be way harder to maintain with unit tests.
If use Ruby on Rails framework, we can run the test in a easy way. It can create a test database, and we can make some fake data. After all the test finished, the test database will be cleaned.
Now want to do the same test with Node.js, Express framework and ElasticSearch. If create index data in the real ES server, maybe not the good way(Think ES as development environment used). Is there a better way to do it as RoR above?
I have researched from internet, but didn't find good example.
I am new on developing in Node.js, I would like to know if there's a way to have ElasticSearch embedded in a Node.js application for testing purposes or if there's another way to test interaction with ElasticSearch without having an ElasticSearch running instance (mock ?)
There are no existing mock libraries for Elasticsearch and Node at the moment. If you know exactly what queries you are going to be performing, you could use a mocking library to mock the entire ES client and assert simple behaviors.
What I'd recommend, however, is actually running ES in a development environment for testing. I find that mocking external services is a pretty tricky thing to do in general, and your tests will likely be much more robust / trustworthy if running against an actual instance of the server.
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.