Skip to content

Latest commit

 

History

History
21 lines (11 loc) · 4.49 KB

File metadata and controls

21 lines (11 loc) · 4.49 KB

Introduction

Welcome, this is somewhat of a add-on to the Understanding Node document, however, I feel testing deserves it's own little section. We wont go into quite as much detail here as we do in the Understanding Node project, as we are going to remain focused purely on testing and writing tests. We will keep this condensed as the Understanding Node segment is already quite a large document for reading, but we will be sure to cover the dos, don'ts, whys, and hows of each tool and library we use. In each section there will be some repetition, remember, repetition is the key to retaining information, but also this will be in the form of sub-paragraphs which may contain TLDR; versions of the larger paragraphs as a quick reference to those just wanting a reminder.

Why bother testing?

Testing is an essential part of development. In order to have faith in our code we need to test it as we go, often many times over, which is a time consuming process. Sadly, this is often a side of development which is overlooked until necessary as it is something which requires at least some understanding of basis code compilation in your language of choice. As such, it is not often beginners are familiar with testing libraries, and even junior to mid level developers can lack experience in testing. Now, you may be wondering what kind of testing I am referring to, after all, can't we just run our app to test it as we go? well... yes, sure, that is one form of testing which we call Manual Testing. In Manual Testing we run our application and interact with it as a user, in this sense we can see how our application is working and, hopefully, tell that it is working as it should. Akin to this form of testing is Regression Testing, this is similar to Manual Testing in that we interact with our application in the same manner as a user would. In Regression Testing however we automate the process by creating functional (QA black-box testing based on cases from the spec) and non-functional (testing for non-functional requirements, the way the system operates rather than specific behaviours) tests. In Regression Testing we automate the entire software package, there are a variety of techniques in performing a regression including stepping through manually, running a test-suite etc... the idea is to find bugs after a change has been submitted to the code base to ensure we have not in-advertantly changed our functionality.

We also have unit tests, these are the tests which we often write to test our functions as developers. Unit tests are a cornerstone of TDD (test-driven development) such that we write tests prior to writing our code, then write the code to allow them to pass (ideally). Unit tests are great for testing small, isolated, units of code and giving us confidence that our functions behave as we expect with all possible inputs. We should try and follow TDD to prevent writing tests feeling like chore after-the-fact and more integrated into our development process. Building up from units we also have integration tests, these tests how multiple units of code work together. This can be the interaction of different components or even microservices.

Functional tests test a particular function of a software (behaviour). For instance, if we are testing a LoginPage we would test the functionality of the Login, making sure that the user is able to enter their password, hit submit, and have the next page either render, or have an error message display should the password be rejected. This itself can be a unit or even an integration test. The keystone of functional tests is that we are not testing code (unlike the goal of unit and integration tests). Much like Regression we are actually testing the behaviour of our application from a user perspective.

Finally, we have acceptance or end-to-end tests, these require an actual browser, are usually performed by a testing team manually, but are often also automated using a software like Cypress or Selenium. This is because they require a real server rather than simply mocking the request and response cycle as we do when writing other tests.

These are the main kinds of testing we mean when we say "testing" as software developers, but, it should be noted there are many other kinds of testing ranging from penetration testing to localisation testing and many more in between.