Having automated testing ensures that we are creating bug-free code, and also ensures that there are no regressions introduced from new code. JHipster helps to an extent, by creating unit and integration tests for the generated code, but in real use cases, it won't be sufficient. We would have to add server-side unit tests for the business logic that we introduce and integration tests for new APIs we add. You will also have to add more unit tests for business logic handled on the client side and e2e tests, as JHipster only generates a few sample tests for you and doesn't know anything about your business logic.
Testing and continuous integration is an integral part of full-stack development and is an important aspect of DevOps. Testing should be considered as important as developing features to build a quality product. Continuous integration is nothing more than continuously merging and testing your new code changes in an isolated environment against your master/main/stable codebase to identify potential bugs and regression. It is achieved by running automated unit, integration, end-to-end, and other test suites against the code. For example, if you are working with Git, these are typically run for every commit you make to your master branch and/or for every pull request, you create.
Once we have automated tests, we can make use of continuous integration practices to make sure that any new code we introduce doesn't cause any regression in our stable code base. This will give us the confidence to merge new code and deploy that to production.
Modern DevOps teams often go a step further and do continuous delivery (continuous integration + continuous deployment). They often define CI/CD pipelines, which continuously integrate, test, and deploy code to production in a fully automated way.
Have I stressed the importance of continuous integration enough?