Too often forgotten, but never useless
The proliferation of JS frameworks makes it even easier to develop a front-end application, requires less and less time and resources, and unfortunately, we often forget one essential thing: to test your application properly before putting it into production.
With all this ease of development, you might not realize that if you tested your application from the beginning, it would save you a lot of time on fixes afterwards …
What are JS front tests?
If you are asked what the implementation of a back-end test strategy consists of, everyone is able to give an example: unit tests, API testing, performance tests, load tests, …
It seems obvious to everyone (it really should be…) to test the back-end, because most of the time, the business logic is found there in the code.
So what about front-end testing and is there any use for it? If you read this article, you can imagine the answer:
YES, it is possible to set up a test strategy on the front application side, and it is even essential!
As on the back-end side, front-end applications can set up a large number of equally useful test types:
- Unit tests: unitary verification of the behavior of a function
- Functional tests: check the validity of a use case defined in the project specifications
- Stress tests: check the site’s behavior beyond the limits of its expected workload
- Load tests: check that a function remains accessible despite a large number of connections to the functionality
- Supervisory tests: check repeatedly that a user can access a function of the site
- Security tests: verify that the information system protects data and maintains functionalities as intended
- Good practice tests: verify compliance with good development practices for a modern website
- Accessibility tests: check compliance with standards and accessibility standards for access to your website to the greatest number of people
- User tests: check the satisfaction of the target audience (not to be confused with customer satisfaction)
Ok, but how do you know which tests to implement ?
Define the test strategy
The first thing to do is to define the test strategy to establish. The goal is not to test for fun but to test effectively.
Some questions to ask yourself before starting:
- What is the criticality level of my application?
- What is the budget for my project?
- What is the expected level of performance?
- Do I have business code in my front-end application?
- How big will the source code of my application be when published?
- Do I have a contractual deadline to correct and restore a service?
- What is the level of knowledge concerning “tests” of my project team?
Once these questions have been answered, you will have a clearer idea of what to implement in your front-end application.
The next step is to list your test typologies to implement as a priority on your project.
Personally, I would tend to prioritize the tests in this order, by importance and according to the cost of implementation and the ROI (return on investment):
In order to help you in your choice of test typologies to set up, here are some keys to help you answer the questions asked above:
It is obvious that the same artillery will not be released between your sister’s website and the twitter PWA application.
You have to know how to put the cursor in the right place. but most often, this cursor is already given in the project specifications, you just have to interpret it well.
Depending on the criticality of the project, the prioritization of the implementation of the test typologies could be slightly different.
The choice of test typologies must also be made according to the project need:
- If the project processes sensitive data, it will be necessary to prioritize security tests
- If the project is intended for a public market, accessibility will be compulsory and therefore may be a priority
- If the application is used by a very large number of users, then it may be necessary to favor load tests or stress tests
2 : Budget
Unfortunately, it is very often this point that decides the test strategy. The larger the budget, the more you can set up different test types.
User testing, and unit testing should be the minimum implemented on any project.
These are also the tests with the highest ROI. The efficiency of these tests will allow a significant saving of time at the end of the project and during the acceptance phase by reducing the number of regressions, anomalies and therefore number of exchanges with the customer.
Best practice tests are inexpensive to set up, so it’s worth adding them to your strategy.
For other types of test, they are generally more expensive.
It is up to you to see whether to implement these tests on the entire application or to target some functionalities in order to reduce the cost, and according to the needs and criticality of the project.
3: Expected level of performance
Will your app be used by 100 users or 1 million? In how many seconds a page of your site must open for it to remain a suitable time? What could be the peak of use over 1 hour or at a time T?
These are the types of questions that must be asked before starting the project. Even if these will only be estimates, they will have a strong impact on the architecture of the project and on the test strategy to be implemented.
The higher the expectations on the performance of your application, the more rigorous the tests will have to be.
The following test types are perfectly suited to address these issues:
- Stress test
- Load test
- Supervision test
But nothing better than to organize user tests before production to have objective feedback on the performance of the application.
4: Business code — user interface ratio
We are not going to lie to each other, it’s useless to test everything in a front-end application (whereas on the back-end side the question could arise).
If you want to implement unit tests, do it only on the business code of your application.
There is no (or very little) added value to test an application which only displays the result received by a web service. If this is your case, it may be better to set up some back-end API tests which will be more efficient in verifying the validity of the data.
If, on the other hand, your application processes data, transforms it, manages a local database, uses service workers, or forms, etc … then unit tests take on their full meaning!
Likewise, if your application only offers one page to users, it might not be worth setting up functional tests. You would spend more time setting up the testing mechanism than writing the tests themselves.
But the more pages and features your app has, the more functional tests or UI tests will make sense.
5 : Source code size
Similar to the previous point, if your source code is only 50 lines long, is it really necessary to set up a full testing mechanism?
The implementation of tests has a cost, so you need a minimum of material to test to make the implementation effort profitable.
The more your application has a large source code, the more meaningful the tests will be, because the greater the risk of regression.
This is true for existing applications, but also to applications that are likely to grow in functionality later.
If the source code of your project is (or will be) important, it is essential to implement unit tests and best practice tests in order to reduce the technical debt, and therefore to save time and money later .
6: Contractual correction deadlines
Contracts with customers very often include deadlines to correct anomalies reported on their applications (example: 2 hours for a blocking bug, 1 day for a major bug, 5 days for a minor bug, etc.)
This has an impact on your testing strategy.
The shorter the deadlines, the more proactive you need to be, and the more important the tests will be to monitor, report, identify and analyze your application.
If unit tests are correctly performed, you will be able to verify very quickly that a regression dit not occur within the application in production.
Supervisory tests also make it possible to anticipate anomalies by reporting an access problem to a feature, as well as for functional tests.
7: Knowledge of my project team
The last important point, but not the least: does your project team have knowledge about the tests to be implemented?
If so, then all is well, the project is in good hands!
If this is not the case, it is important to include in your strategy the development of team competence: either through training or through the accompaniment of an experienced person or service.
It may also be necessary to rule out certain types of test if no one has the knowledge to set it up, to refocus on other types of test.
When to set up the tests?
The more consistent the application becomes, the greater the risk of missing an anomaly.
The best time to implement a testing strategy is during the application design phase, before you start coding.
Once this strategy has been established and validated by the entire team, the tests can be written as the development progresses.
It may also be a good time to train the teams to use tests. Which will be much more complicated to organize once the project has started.
But if your project already exists or has already started, it is quite possible to catch up and set up the tests afterwards. Be aware that it will take a little longer.
Define the methodology
How to integrate the implementation of tests in an application? There are several methodologies for organizing the writing of tests:
- TDD (Test Driven Development): Test Driven Development is a software development technique that advocates unit testing before writing the source code of the project.
- BDD (Behavior Driven Development): recommends bringing together in a single document requirements (User Stories) expressed according to the “role-function-benefit” formalism, and scenarios or examples expressed according to the “given-when-then” framework. Can be combined very well with TDD.
- ATDD (Acceptance Test-Driven Development): Management by business tests. Tests are created and automated prior to development
- RJD (Rush Job Development): Implementation of tests after writing the source code in order to guarantee minimum regression
There is a lot to say on the subject, if you want more information you can consult this more detailed article: Overview of TDD, BDD and ATDD techniques
Choose a team to work on this project
It sounds simple but it is nevertheless a crucial point for the success of the implementation of a testing strategy on a project.
To explain why this is important, here are a few sentences that I have already heard about my various professional projects:
“Keep the costed budget for the tests for the end in case we run out of budget” Manager X
“We will do the tests at the end if we are not too late on the schedule” Manager Y
“In any case, it is useless to test a front-end application” Developer X
“I do not know anything about testing, I will see it as I develop” Developer Y
Do you think that these projects were able to set up a good testing strategy? Obviously not.
Setting up tests on a project has a cost and takes time!
1st person to convince in a team: the manager!
He must validate the fact of quantifying the tests in the proposal made to the client or that the delivery times are extended compared to a project without tests.
Once the manager agrees, don’t let go!
This is probably the hardest part, but if you give in early on and the tests aren’t put in place… they will never be set up!
2nd person to persuade: the developer (s).
It must be admitted, the implementation of tests is not the preferred part of developers.
But we must make them understand the interest of having tests in their application:
- Fewer regressions therefore fewer anomalies to correct subsequently
- Fewer manual tests to perform
- Less feedback from “pests”: Project manager / Manager / Client / Commercial / etc…
- More automation
- New skills to acquire
A question often comes up: Is it mandatory to take developers who have already done the test?
Yes and No: personally I recommend 1 person with experience on the subject in the team to increase the skills of others more quickly.
For example, a junior developer working on unit test writing will progress less quickly on this part at the start of the project, but will progress very quickly if he is well trained or well accompanied.
The main thing is that the developer is not resistant to testing, which will inexorably lead your strategy to failure.
3rd person (optional): the test manager or qualification team
Depending on the project, a dedicated sub-team may be responsible for writing tests. This applies very well to BDD and ATDD methodologies for writing functional tests.
As far as technical tests are concerned, I recommend that this person be integrated into the development team, allowing for example to set up peer-programming test / development.
The technical test must always remain as close as possible to the development team who have knowledge of the source code and the functions to be tested.
4th person: the customer!
And yes, as a customer, you will have to pay more for a properly tested application.
But a well-tested application is a guarantee of quality and safety and will save considerable time at the end of the project.
It is always more pleasant and reassuring to deliver a tested and validated application, than an application on which 1234300 anomalies are reported during the 1st week of acceptance.
Before setting up the tests on a project, you have to ask yourself the right questions:
- What testing strategy do I want to implement?
- When do I put it in place?
- With what methodology?
- Which team for this project?
If you have the answer to these 4 questions, the hard part is done!
All you have to do is select the tools that will allow you to implement your strategy.
Did you like this article ? Support Me With 42 Claps and Follow Me on Twitter for more content on the Web and Mobile.
If you would like to contribute to this article and help me translate it, please contact me 😉