Mastering the art of front-end development entails more than just crafting visually stunning and user-friendly interfaces. It also demands an understanding of robust testing protocols to ensure the seamless operation of your application. Whether it’s concerning the user interface, user experience, backend communication, or preventing crashes, a front-end developer is tasked with ensuring each component functions as expected. But how do you effectively check your work and guarantee that you’ve left no stone unturned? That’s precisely what we’re going to delve into today – the art of self-testing as a front-end developer.
Before we kick off, it’s important to understand that self-testing doesn’t merely mean verifying if your application works. It goes deeper than that. It’s about affirming the quality of your work, from code readability and structure to the execution of intended functionalities. So, let’s dive in and explore how you can level up your self-testing game.
If we are talking about the testing of the front-end part of the apps, it’s pretty obvious. You just need to check a list of things:
- User interface (whether everything looks okay on different screen sizes, every button or touchable element is easy to interact with and so on),
- User experience (are all the forms easy to complete from the user perspective,
- Does the user feel comfortable using the app in general and there’s nothing preventing him/here from getting what he wants from the app),
- Whether the communication with the back-end part is correctly managed (requests, connection to sockets and so on, including processing errors and notifying user about them),
- Make sure that the app doesn’t crash.
That’s basically it, but we’ll also talk about it. However, if we are talking about self-testing, it’s more like checking whether you made your job right. Let’s dive into the details.
Part I. Code structure
Whether you are working on the web app, mobile app or desktop app, it’s always necessary to make sure that your code is readable. It means that a person who is not involved in the development process but still has a necessary experience can read a code and easily add some functionality to it. Here are some recommendations:
Separation of concerns
Basically when you are developing an app, you can split it into separate parts. For example, in web development everything is pretty straightforward: markup with HTML, add some styling with CSS and some logic and interaction using JS. But the JS part itself can be also split into parts: interactive elements, communication with API, dealing with state management (Redux, Flux, Mobx and similar), some small helpers to deal with data (like formatting strings, dates and so on). You can continue and make sure that the class responsible for some task doesn’t make anything it’s not responsible for.
Learn some “abbreviation” principles
There’s a lot of them so it would be enough to do scientific research. But there are some pretty simple principles like DRY (don’t repeat yourself) or KISS (keep it simple, stupid). They are self-explanatory and pretty obvious. But there are some principles that need a deeper understanding like SOLID, CUPID and GRASP. Sometimes you will even be asked about them on the job interviews so it’s definitely useful to check them out:
https://www.boldare.com/blog/solid-cupid-grasp-principles-object-oriented-design/
Get rid of the huge files
At this point if you followed all the principles and splitted everything depending on the responsibilities you should not have some files with thousands of lines of code. But if you do, don’t. Just split them into smaller parts (components, separate smaller functions and so on). Your colleagues and newcomers will definitely thank you.
Part II. Code appearance
Linter
You should definitely find one. It just checks whether you have something nasty in the code like unused variables/imports, array functions where they should not be used or some comments in the code. Basically, you may be the best developer in the world but you are still a human so you can forget about something. Don’t make your code smell, let a linter help you.
Prettier
If linter will make sure you don’t leave something that is not supposed to be in the code, prettier will help you to make everything else look… pretty. It will take care of the spacing, tabs vs spaces, line breaks after commas etc. You can even make it do its work when you save a file. It’s a very useful tool and extremely easy to use too.
Split the method chaining
It may look cool and actually reduce the lines of code. However, if the chain is too long, just save the result of some part of it to a variable and keep the process from a new line. It’s debatable but it will be more readable.
Take care of the naming convention
Linter will not tell you your variable is called wrong. So just follow a common sense and think whether everything is written in English and classes/variables are called correctly.
Part III. Triple-check the leftovers
Just check what you added to the code and before pushing the changes to the git repository or making a new build, delete everything that is not supposed to be there. Sounds silly but it’s very important.
Check the environment
Development, staging, production… Just make sure that the app is pointed to the correct API.
Delete all the things you use for debugging
Remove comments and alerts. It will make your code cleaner and will prevent you from making a new build without necessity.
Check the styles
Sometimes you may use background colors or borders to see where the component is. Make sure you remove that.
Check the routing
Make sure that every route is in its place. If you switched the components on some routes, reverse the changes.
Remove the API responses from the screens
If you added some response from API on the page/screen just not to open the developer console, remove that.
Part IV. Literally testing
Basically there is a position called QA analyst or even QA engineer. They are responsible for testing the end product on every stage of development. However, there is a lot of work the developer needs to do before sending the product to the QA engineer. Let’s take a look at that part.
Static testing
That’s basically everything that was described above in the previous parts. You need to make sure that the code looks nice and professional.
Unit, integration and system testing.
Basically it is a separate parts of the whole testing process. Unit testing is about testing small parts of the app like functions or classes, integration testing makes sure that those parts work together in the components and system testing is a testing of the whole app. In simple words, this type of testing involves writing some code to make sure that your main code works fine. There’s a list of tools that can help you with this task. For example, in Javascript we can use these:
- Jest, Jasmine or Mocha for the basic functionality
- Chakram or Frisby.js to test REST API
End-to-end testing
It means that your app needs to meet the business logic requirements. In this case the automation libraries may come in handy, like Selenium or Cypress. Also if you want to test the REST API outside of your app to make sure that the backend developers are the ones to blame, you can use Postman or Insomnia.
Smoke testing
Just check if your app works in the most simple scenario. Don’t try to break it with big data or incorrect user data provided in the form. The app just needs to work in some basic functionality terms.
There’s a lot of other testing types which involves user acceptance testing, usability testing, alpha and beta testing and so on. But these types of testing are not always run by a developer but rather by DevOps or QA analyst.