I've built a web app that aggregates trading and blockchain data from several API's and displays them in a React frontend(node backend)
What is the best way to implement tests to check for data integrity or when there are issues?
I am extremely new to testing and would appreciate any guidance/direction. Have gone through several testing frameworks and libraries, and am kind of dumbfounded.
You don't really test apps for 'integrity' of data as you name it.
Especially when data comes from external (not your DB for example) sources.
If you own data, you can test DB integrity, but as you say that is not the case here.
What you do though is - write unit tests (functional, recursive, end2end tests too, but what you want to do will mostly be achieved by using unit tests).
Within tests, you basically provide all kinds of data to your app and check if results are what you expect them to be (both for working and breaking scenarios).
This way, you can be sure it works as you designed it.
If at one point somewhere in future, a bug is exposed or you find it yourself. Define precisely why the bug occurs and add test for it.
When after you fix code responsible for bug, all of your tests pass, you know you are good again.
As for libraries:
"Jest" https://jestjs.io/ is go-to library for many - it's for unit tests mostly.
Jasmine and Mocha are also popular choices.
For end to end testing check Testcafe - I recommend it.
https://github.com/DevExpress/testcafe
You should also test your API with Mocha, Chai, Supertest or Chakram.
This way, all layers of your app are covered and bugs can be spotted quicker.
Related
I am a junior web developer with inspiration in backend and data engineering. My background is mechatronics engineer but ended up in software engineering because of the number of job opportunities. I learned that frontend and backend are somewhat bounded together: oftentimes frontend leads with user-interfacing while the backend resolves the database issues and provides the necessary frontend services. Along the development journey, testing is necessary and oftentimes tries to be necessary, to avoid any issue on use cases.
After this preamble, I ask your help for testing this open-source app boilerplate that I write on this repository: https://github.com/web-needle/sappio . The first issue request regards jest coverage, which shows an empty coverage table, although there is 4 passing tests. The second and last is to provide some tips on testing of middlewares and routes.
I have issues with postgres database as well, but I think here is not the proper place to do such question
We're using in our product Jest for Unit and Integration tests.
At the moment, we're searching for a solution to measure the duration of scenarios (Unit, API and E2E level) between two CI/CD builds, to see if code changes lead to performance decrease/increase.
There are solutions outside like JMeter and Gattling, but it feels not a right fit. On the one side, you have to write tests again that we already have written in Jest. And on the other side, these tools are more focused on Load, Scalability, Breakpoint, Stress testing etc. which feels a bit over dimensioned for our use case. (We're using completely serverless architecture, and we only want to know if code changes have an impact on performance)
So I was thinking if it's not maybe simply possible to utilize the Jest tests that we have already written, to measure also in some way the performance and compare it between CI/CD builds.
Do you know if there is some library or tool that could help me with that? Or do you have perhaps a complete different opinion, how to approach that?
I have a question about how best to do end-to-end/integration testing without having to mock an entire API. I've not found any great solutions and I'm starting to wonder if I'm thinking about this the wrong way.
My situation
I have a web client that I want to test which relies heavily on a REST API that is part of our larger system. For the most part, testing against an instance of the real API service seems like the right thing to do in our end-to-end testing scenario, but in some cases (e.g. provoking errors, empty lists et c) it would be easier to mock portions of the API than to go in and change the actual state of the API service.
In other cases, I don't need to mock the API, but I do need to confirm that requests were made as expected, essentially a spy, but on an API.
My idea for a solution
I imagined the best way to solve this would be an HTTP proxy controlled by the test suite, sitting between the system-under-test and the API service. The test suite would then:
Configure the system-under-test to use the API proxy
For each test
Set up mocks only on relevant endpoints (the rest are proxied to the API service)
Exercise the system-under-test
Make assertions by reading spies from the proxy
Tear down/reset the mocks and spies afterwards
I have multiple use cases for this, one being Cypress end-to-end testing inside a browser, where monkeypatching or dependency injection is not possible, because significant portions of the system under test is not executed directly by the test-suite.
I found MockServer which seems to solve what I'm looking to achieve, but in a massive Java program that adds a lot of requirements (e.g. Java, which translates to CI costs) to an otherwise node-based environment.
EDIT: This image from MockServer illustrates one usage which matches my scenario:
My question(s)
Is what I'm considering a good approach to this type of situation? What is a good way (e.g. existing software) to solve this within the Node eco-system?
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.
I am considering using MS Bot Framework, mainly for the ability to write unit tests, instead of testing through the messenger. I did some digging around and found several questions about testing that lead to examples of tests.
The issue was that the tests contained the actual bot logic, which is kinda dumb considering that in tests you normally only write the requests and check the responses/results to be equal to something. So is there a way to handle tests with just starting the bot locally and not copying its logic to the tests?
It's theoretically possible, but highly impractical.
It would involve copying a large part of the BotBuilder Emulator code (itself requiring a substantial amount of time to go through and understand), and running that within the test environment. Also, I have found that when I attempted this with the actual emulator, the tests failed with the responses from the bot going to the emulator and not to the test as expected.
The more practical solution is to use an NPM package bot-tester that can simplify the test, or using the general methodology of including the bot logic in the tests themselves as is the norm. Either way, some bot logic would have to be included in your tests.