Testing Our Product
In the previous chapter, we finished the frontend development. Does it mean we are done with the development? No! Writing tests is also part of development. In this chapter we will discuss what types of testing there are out there, how to do them, and whe
- PDF / 1,065,770 Bytes
- 28 Pages / 504 x 720 pts Page_size
- 4 Downloads / 171 Views
Testing Our Product In the previous chapter, we finished the frontend development. Does it mean we are done with the development? No! Writing tests is also part of development. In this chapter we will discuss what types of testing there are out there, how to do them, and when to use them. In this chapter we will explain the difference between manual testers and automation testers and discuss several testing platforms and frameworks. We hope you enjoy and that by the end of this chapter you know how extremely important that topic is.
Different Types of Testing Different types of testing serve different needs. It doesn’t mean that one can be used in favor of the other or that some types are better than others, all of them have their purpose, and, depending on the nature of the project, some might be more important than others. This section discusses some types of testing, the ones we believe are most important for our use case, but there are more, and we invite you to take a look if you are interested.
Unit Testing As the name states, unit testing means testing a small part (units) of code. This kind of testing is done as individually as possible, meaning that it is advisable that the code being tested runs isolated from other pieces of code. In most of the cases, what’s being tested is a method, a class, or even a module, and the test cases should be independent from each other (e.g., test B must not be expecting that something is created by test A in order to pass). Depending on the nature of the application, the setup can be more or less complex. In our case, for example, we need to handle database calls; this means that we had to set up everything in a way that all the database changes are only valid during the test and then discarded. © Olga Filipova and Rui Vilão 2018 O. Filipova and R. Vilão, Software Development From A to Z, https://doi.org/10.1007/978-1-4842-3945-2_7
181
Chapter 7
Testing Our Product
This kind of testing is the first line of defense for your code. You might ask, “Why do I need to write this test if I can just verify if manually?” It is a good and valid point, but only if you assume that your code will never change, and we all know that is not true in most (if not all) of the cases. Writing unit tests will prevent further changes to break your code base in the future, since you are asserting the expectations of several actions. If tomorrow your new colleague is performing the task of changing something and deletes some parameter you were using before, the test will fail. Sometimes it is common to use Parameterized Unit Testing, meaning that the input is generated by the testing framework and not by the one writing the tests. In most cases, it is hard to set up these kind of tests since the modules being tested are too complex. Imagine that we were to use parameterized tests to test the user creation. Our restrictions with passwords and e-mail would make it complicated to provide a good seed to generate data. On the other hand, if you just created a memory structure, such as a list or
Data Loading...
