The short guide on implementing automated testing in Meteor projects

Dec 11, 2020
In a world, where an hour of enterprise server downtime costs more than $300,00 for 86% of surveyed entrepreneurs, the importance of regular and efficient testing is undeniable. Detecting bugs before they ruin our user experience is crucial: users are ruthless if they encounter technical issues.
90% of all apps are used just once and immediately deleted afterward, mainly because of freezing (76%) and crashing (71%). Since 84% of users abandon an app after two crushes, preventing technical issues should be every company’s top priority. Luckily for all developers and entrepreneurs, their programming prayers have been answered and thanks to automated testing, it has become easier than ever to spot problems before they arise and fix bugs before they destroy our business.
Automated testing is in line with DevOps strategies, which are designed to reduce costs, encourage faster growth, improve ROI, and improve quality. By automating your testing, you can significantly maximize your text coverage, simplify regression testing, and improve the process of smoke testing. How to implement automated testing in a Meteor project and save yourself from technical disasters, costly outages, and angry users? In general, the process of testing your Meteor application is similar to testing any full-stack JavaScript application. There are two commonly used testing commands: meteor test command and “full application” test mode activated with meteor test --full-app. Let us explore the process of test automation for Meteor, step by step, and command by command!

The importance of automated testing in the internet-powered world

As the number of ransomware attacks was up by 67% year-over-year in the 4th quarter of 2019, and IBM X-Force alone tracked 150,000 disclosed vulnerabilities, the cost of human error is becoming significantly higher, and testing data volume undeniably bigger. Manual testing is no longer efficient and fast enough to detect potential problem areas for organizations, as it requires constant human supervision and it is time-consuming. Cybercriminals around the world are constantly searching for vulnerabilities in IT infrastructures and if they detect them before the testers, they can break into systems and steal data. Automated testing allows for scheduling system testing and makes it possible to scan large data volumes without human involvement.
Since the tool is programmed to spot anomalies, it is more accurate than human testers: 90% of cloud data breaches can be attributed to human error. With the development of the web, rising numbers of cybersecurity threats, and growing volumes of data, automated testing is essential to prevent bugs, downtime, and data breaches. It is a time-efficient solution, which allows for constant testing at affordable rates. According to Statista, the main risks and challenges affecting server uptime and availability in 2020 include security flaws (64%), human error (60%), bugs/flaws in software (40%), and configuration complexity (35%).
With automated testing, vulnerabilities are detected faster, which is especially important for projects in the initial development phases. Implementation of automated testing in Meteor projects makes it possible to fix potential problems early on, which saves teams both time and money. The more advanced the project, the more expensive it is to make changes, so automation is a high-return investment for emerging companies.

The overview of Manual testing vs Automated testing

Manual testing and automated testing are both valid testing methods, but performance-wise, automated testing has proven to be more effective with shorter data processing time and robust tools for performance testing. Unlike manual testing, automated testing works well for stress testing and load testing, which is extremely important from a business perspective, as downtime is becoming more expensive than ever. The larger the test volume, the better investment automated testing makes. In fact, although manual testing requires a smaller amount of money paid upfront, automated testing has a better ROI in the long run, especially for companies, which plan on scaling. Since manual testing is done by human testers, it involves a high rate of human error, which could be lethal to any company.
With the rising number of cybersecurity threats, the smallest error may lead to a data breach, downtime, or software bugs, which quickly scare users away. Internet users are not forgiving: 38% would delete an app that freezes for more than 30 seconds. On the other hand, manual testing has a slight advantage over automated testing when it comes to exploratory testing and random testing, as automated testing is structured and works in line with pre-determined scripts. If there is a UI change, scripts for automated testing need to be changed completely. In comparison, manual testers can quickly adapt to changes, no script required.
However, given that automated testing allows for in-built verification and testing, it is an essential part of the DevOps life cycle, which is quickly gaining prominence in the industry, automating and integrating the processes between software development and IT teams for faster and more reliable software development.

Choose your test: UNIT, INTEGRATION, ACCEPTANCE, LOAD

Since they are different types of tests depending on your needs and testing criteria, you need to choose which test is best suited for your Meteor project.
  • Unit test
Running unit tests makes it possible to test small modules of applications. In order to test your module, you have to isolate each test and stub and mock the remaining modules. Some of the isolation techniques for uni tests include:
  • The velocity:meteor-stubs package (it creates simple stubs for most Meteor core objects)
  • The hwillson:stub-collections package (it allows for replacing the server-backed client collection with a mocked out local collection, encoded in the package)
To verify if everything works correctly, you are required to investigate, which actions are taken by the module. Since Meteor codebase is split up into ES2015 modules, modules are usually tested one at a time. It is often recommended to combine unit tests with integration and acceptance tests — unit tests are may not detect all the bugs, as they often eliminate dependencies.
  • Integration test
As integration tests verify how multiple modules work together, they often require running code both on the client and server to verify if the communication between the two works well. Integration tests may often isolate parts of the entire application to verify results directly in code.
  • Acceptance test
Sometimes called “end-to-end test”, acceptance tests make it possible to run tests run against any running version of an app, verifying at the browser level that every command works as intended.
  • Load test
Load tests are often called “stress tests” as they determine how much load can your app can take before it crashes. Such tests are especially important before big launches: a 1-second delay in page response can lead to a 7% reduction in conversions.

How to implement automated tests in Meteor projects?

Testing a Meteor app is similar to testing full-stack JavaScript applications, although Meteor’s reactivity makes the entire process a little more challenging. Normally, we can test our Meteor app by using the meteor test command, which switches the app to a special test mode. In such a mode, our application code is not loaded, but the app freely accepts and loads any *.test[s].*, or *.spec[s].* files. As Meteor.isTest flag is set to be true, the test driver package starts up.
Since both Meteor’s built-in tool and test command are designed to ignore any files located in tests/directory, it is possible to use a test runner outside of Meteor’s built-in tests tools without having any files loaded into the application. Why is it important? Well, it makes it possible to write tests in files, which will not be included in the app and will be the only thing loaded in test mode. It is a perfect solution for unit tests and integration tests, as it allows for the quick import of specific modules. Test mode aside, Meteor also offers a “full application” test mode, which can be run with a meteor test --full-app command. It is similar to test mode but unlike test mode, it lets the entire application load normally, which allows for complex integration tests or loading files for acceptance tests. In the “full application” test mode, test files with *.app-test[s].* and *.app-spec[s].* are loaded, just like our application code. In this test mode, Meteor.isAppTest flag is set to be true rather than Meteor.isTest flag. There is one more command, which is used to test Atmosphere packages — meteor test-packages. You must remember to provide a --driver-package argument. It is important because test drivers are mini-applications running in place of your app to run tests and report test results. Main test driver packages include:
  • Console reporters — used primarily for continuous integration, they run completely on the command-line
  • Web reporters — they include a special test reporting web User Interface, where you can see testing results
The process of automating your testing: how to write scripts for different types of tests?
How to create editable scripts, which will easily and quickly adapt to changes in User Interface?
Automate like a pro: things to consider when you implement automated testing
Depending on the testing methods you choose, you will have to follow different procedures, but certain guidelines remain constant for every type of automated Meteor testing. Meteor is known for reactivity, which may be a challenge when testing because when you change a reactive input to the system, you have to wait until the User Interface changes to reflect it. Luckily, there are ways around it: you can use Tracker.afterFlush(). to force all of the pending reactive updates to complete. Another challenge in Meteor testing is creating test data in the client context, but we can overcome this issue by creating a set of data against which we may run our tests. We might either use standard insert() calls against our collections or create factories, which help us to encode random test data (for example, packages such as dburles:factory). The way you handle your automated testing depends on your needs, but many developers choose to execute their testing in the following proportions — 70% of testing focuses on unit testing, 20% on integration testing, and 10% on end-to-end testing. It is worth noting that these are just exemplary numbers and may vary from project to project.

Automated testing in a Meteor project works similarly to testing any full-stack JavaScript applications

All things considered, implementing automated testing in a Meteor project is similar to testing full-stack JavaScript applications, which makes the entire process intuitive for many developers. Meteor’s reactivity is one of the things we must consider when running automated testing on Meteor, but it just takes Tracker.flush() to find our way around it and smoothly progress with our testing procedures. Given that Meteor is fast and innovation-friendly, running automated testing in a Meteor project is a great way to quickly detect bugs, avoid data breaches, and ensure that we will never experience downtime. Since it is better to prevent than heal, implementing automated testing is probably one of the best investments you can make for your company in the long run. Luckily, you’re in the right place — we are here to help you automate your testing to accelerate your growth.
Contact us at info@vazco.eu to get your Big Bang with your web projects!