Best Practices for Web App Testing in JavaScript or Python?

[FaisalKazmi]

Hey everyone,

I’ve been working more on full-stack projects recently, and while my backend is typically in PHP, I’ve started building more with JavaScript (Node.js) and Python (mainly Flask). I'm now focusing more on proper QA, especially around web app testing—functional, unit, and integration testing.

I wanted to ask what tools or frameworks you all recommend for web app testing in these languages?
For example:

In JavaScript, I’ve tried Jest and Mocha but wonder how they stack up long-term.

In Python, I’ve dabbled in PyTest and unittest, but I’m unsure how to scale them for larger apps.

Also, how do you structure your test environments in these languages? Separate Docker containers? VMs? Would love to hear how others in the community handle this.

Looking forward to your input!

[gizmola]

Great question.  

You start with the type of tests and look at tools that are designed for that type of testing.

You've been focused on unit tests, which is absolutely the right way to go.   Unit tests are your basis for set up of a CI/CD pipeline, and the typical dividing point between the things software engineers are responsible for, and the things that QA is responsible for.

There are "suite" tools I've used in the past like https://codeception.com/ that are designed to support many different sets of tools,  as the basis for building out a complete set of automated tests of different types.

With that said, I'm going to copy this from a pretty good article series Atlassian has here:  https://www.atlassian.com/continuous-delivery/continuous-integration

 

Quote

The different types of tests

1. Unit tests

Unit tests are very low level and close to the source of an application. They consist in testing individual methods and functions of the classes, components, or modules used by your software. Unit tests are generally quite cheap to automate and can run very quickly by a continuous integration server.

2. Integration tests

Integration tests verify that different modules or services used by your application work well together. For example, it can be testing the interaction with the database or making sure that microservices work together as expected. These types of tests are more expensive to run as they require multiple parts of the application to be up and running.

3. Functional tests

Functional tests focus on the business requirements of an application. They only verify the output of an action and do not check the intermediate states of the system when performing that action.

There is sometimes a confusion between integration tests and functional tests as they both require multiple components to interact with each other. The difference is that an integration test may simply verify that you can query the database while a functional test would expect to get a specific value from the database as defined by the product requirements.

4. End-to-end tests

End-to-end testing replicates a user behavior with the software in a complete application environment. It verifies that various user flows work as expected and can be as simple as loading a web page or logging in or much more complex scenarios verifying email notifications, online payments, etc...

End-to-end tests are very useful, but they're expensive to perform and can be hard to maintain when they're automated. It is recommended to have a few key end-to-end tests and rely more on lower level types of testing (unit and integration tests) to be able to quickly identify breaking changes.

5. Acceptance testing

Acceptance tests are formal tests that verify if a system satisfies business requirements. They require the entire application to be running while testing and focus on replicating user behaviors. But they can also go further and measure the performance of the system and reject changes if certain goals are not met.

6. Performance testing

Performance tests evaluate how a system performs under a particular workload. These tests help to measure the reliability, speed, scalability, and responsiveness of an application. For instance, a performance test can observe response times when executing a high number of requests, or determine how a system behaves with a significant amount of data. It can determine if an application meets performance requirements, locate bottlenecks, measure stability during peak traffic, and more. 

7. Smoke testing

Smoke tests are basic tests that check the basic functionality of an application. They are meant to be quick to execute, and their goal is to give you the assurance that the major features of your system are working as expected.

Smoke tests can be useful right after a new build is made to decide whether or not you can run more expensive tests, or right after a deployment to make sure that they application is running properly in the newly deployed environment.

 

So in each category of testing, there are different aims, and different environmental dependencies,  tools and approaches.  This is why in most mature companies, especially if they are offering SaaS or PaaS they typically have a well resourced QA department with QA Automation engineers, as well as QA Analysts/Testers, who come up with the testing plan, and are responsible for pass/fail.  They'll often work with an automation engineer, who is typically concentrating on Integration and UI tests.  So when you get into those areas, that is where you are more likely to require a more fully functional "test environment".  Often it takes a good amount of effort, usually involving devops, to be able to build up/tear down a full/independent test environment, not to mention the time and resources involved.  With containerization, cloud services, kubernetes etc, there are many different approaches that might facilitate this, so it depends on what/how you are deploying into production.

Going back just to unit testing, which is where you are concentrating initially, I've found one of the most common areas of pain for unit testing is in "mocking", and the most common place where you might find an additional library to facilitate mocking, even if you are still using the de facto unit testing tool for the language.  For PHP that would be an example of using something like "mockery" along with "phpUnit" even though phpUnit has its own mocking features.  You also have to evaluate and decide what amount of code coverage is acceptable to you, and what tradeoffs might be involved.

When you start looking into this you will find that there are a lot of opinions about certain tools/services.  This article does a really good job providing you some background on this:  https://djangostars.com/blog/continuous-integration-circleci-vs-travisci-vs-jenkins/

When you start looking into self hosting with something like Jenkins, you will find a lot of different opinions on it as a platform.  Same goes for all the alternatives.  You also have things like github actions or bitbucket pipelines.  They might offer you a good way to move towards CI, although they tend to be limited in comparison to the other options. As I have projects which are using Bitbucket repos (as well as the atlassian suite, particularly jira) I've been working on their tools and find them to be a good way to start, but if I had them in Repo I would probably be trying to see what I could get out of actions as a first step in this direction.

CD is also a nice goal to have.  The more your work is built to take advantage of the foundation of containers, the more options you will probably find you have.