There are many ways to approach testing. For this guide, I’m going to focus on just a few of them.
First, let’s think about what’s included in a test. Applications are often divided into tiers or layers such as the presentation layer, application layer, and database layer. One type of testing is end-to-end testing, which starts from the end-user perspective and goes all the way back to the database layer. The goal here is to ensure that when an end user provides certain inputs, the system produces the desired outputs. Usually there’s a lot happening in between.
Integration testing checks that various components of your system work well together. There’s not a very precise definition of “component”, but the idea is that we’re testing some aspect of functionality without breaking it down to the most fundamental parts. In most architectures, if you’re involving a database or other system external to your application code, it’s considered integration testing. In our case, we’re testing code deployed to MarkLogic, a database management system, so the database is inherently closer to our application than with other architectures.
Unit testing looks at the smallest part of your application, typically a single function. By passing in a variety of inputs and verifying correct outputs, we can be confident that the foundation pieces with which we’re building our application work as expected. Note that with any type of test, we want to see that our application behaves as expected whether the inputs are valid or not.
These types of tests are all functional testing: does the code do what it’s supposed to do? The marklogic-unit-test framework enables scripting of unit and integration tests. Knowing that our units and components work as expected builds confidence in the results we get at the system level, as well as helping us narrow down where to look if something does go wrong.
There are a variety of non-functional tests as well: load, stress, performance, compliance, usability, security. With marklogic-unit-test, we can get into some types of security testing, like validating that queries don’t return results that they shouldn’t. But testing that the server itself is properly secured, along with other forms of non-functional testing, fall outside the scope of this framework. Just for the record, these are all important as well, but they require different tools and different approaches.
We can’t talk about types of testing without mentioning the role of human QA. Our automated tests don’t take the place of a human looking for ways to break the application — humans are very good at breaking things! Both have their place. Human QA testers bring ingenuity, curiosity, and a different perspective from the developer. Automated tests bring the ability to run a very large number of tests quickly. Ideally, you’ll use both to build confidence in your code.