1. Introduction

When we talk about testing, we mean empirical tests to improve the quality of our code. A set of techniques that reliably assess resistance to failures.

Throughout the course I will use Python with the pytest library to illustrate the examples. Not because testing is a Python thing, but because we need a concrete language to bring the theory down to earth. The patterns you will see are universal: they work in any language and with any testing framework. If you come from another ecosystem, translate the syntax and keep the idea.

{: .advice } This is a course about concepts, not a pytest manual. If you want to go deeper into the tool, at the end of the course I leave you an article dedicated solely to that.

There are a great many approaches and families of tests. Let's put them in order.

Philosophies

Tests depending on visibility

  • White-box testing.
  • Gray-box testing.
  • Black-box testing.

Tests depending on application execution

  • Static testing.
  • Dynamic testing.

Functional testing

Non-functional testing

  • Performance testing.
  • Security testing.
  • Random testing (Fuzzing).

Tests according to the number of tests to run

If it is a short job there will be an initial investment of time, but as the flow grows productivity will increase by being more linear and controlled. Before you tell yourself "I'm not going to do testing because it's too small", I want to remind you that every project starts out small. Later you won't find the energy, it will be too big to test or document.

Chart of why you should do testing

What advantages does testing have?

  • It increases the quality of the project and the code.
  • It reduces errors when adding new features.
  • Less time when fixing bugs.
  • It increases the use of good practices.

Cons?

  • It increases development time.
  • It increases complexity.
  • Many developers don't have the habit, so there will be some initial resistance and a need for training.
  • It is hard to test old code.

In exchange, the quality of your code won't be compromised. If the client works with your application they won't experience technical problems. Maybe they won't quite like the size of a button or the color of some text, but they won't come knocking at your door with a list of bugs. And consequently you'll sleep soundly.

White-box testing

These are tests focused on the source code, knowing what we input and what results we expect. Always using different input values and knowing the return values in advance.

Levels

  1. Unit test (Unit Testing): a function or object is tested individually.
  2. Integration testing (Integration Testing): a set of functions or objects that interact with each other is tested.
  3. System testing (System Integration Testing): the whole software is tested in full.

Differences between testing types

Supporting material

TDD flow diagram

In the next topic we will develop unit testing.

This work is under a Attribution-NonCommercial-NoDerivatives 4.0 International license.

Desafíos de programación atemporales y multiparadigmáticos

Desafíos de programación atemporales y multiparadigmáticos

Te encuentras ante un librillo de actividades, divididas en 2 niveles de dificultad. Te enfrentarás a los casos más comunes que te puedes encontrar en pruebas técnicas o aprender conceptos elementales de programación.

Buy the book

Will you buy me a coffee?

This is how I keep writing without ads or paywalls.

Comments

There are no comments yet.