Fundamentos del Testing en Python
¿Qué son las Pruebas Unitarias y por qué es importante?
¿Qué es el Testing en Software?
Instalación y Configuración del Entorno de Pruebas
Conceptos Básicos de Unittest
Cómo Crear Pruebas Unitarias con UnitTest en Python
Cómo usar el método setup en tests de Python
Uso de tearDown para limpieza de Pruebas Unitarias en Python
Cómo validar excepciones y estructuras de datos con Unittest en Python
Control de pruebas unitarias con unittest.skip en Python
Organización y Gestión de Pruebas
Cómo organizar y ejecutar pruebas en Python con UnitTest
Mejores prácticas para organizar y nombrar pruebas en Python
Técnicas Avanzadas en Pruebas Unitarias
Mocking de APIs externas en Python con unittest
Uso de Side Effects en Mocking con Python
Uso de Patching para Modificar Comportamientos en Python
Exploración de Herramientas y Métodos Complementarios
Cómo parametrizar pruebas en Python con SubTest
Documentación de pruebas unitarias con Doctest en Python
Cómo generar datos de prueba dinámicos con Faker en Python
Mejora y Automatización de Pruebas
¿Cómo asegurar la cobertura de pruebas con Coverage en Python
Automatización de Pruebas Unitarias en Python con GitHub Actions
Pruebas Unitarias con PyTest en Python
Cómo crear pruebas unitarias con inteligencia artificial en Python
You don't have access to this class
Keep learning! Join and start boosting your career
If you already have an account,
Resources
Naming tests correctly is key to team success, facilitating code understanding and effective collaboration. Although not mandatory, having a clear format for tests is very beneficial.
How to define the format of test names?
- All tests should be grouped into classes, each related to a class in your project. For example, if you have a class called
BankAccount, the test class should be calledBankAccountTest. - Each test should begin with
test_, so that testing tools can easily identify it. - The next element in the name should be the method you are testing. If it is a
depositmethod, the name would betest_deposit_.
How to structure the test scenario?
- After the method, add the scenario. This refers to the values or parameters you use in the test. For example, in the case of a positive value in a deposit, the scenario would be
positive_amount.
How to describe the expected result?
- To finalize the name, indicate the expected result. If the deposit increases the balance, add something like
increase_balance. Thus, a complete test name would be:test_deposit_positive_amount_increase_balance.
Why is this format useful?
- It allows any team member to understand the purpose of the test without reviewing the entire code.
- It facilitates code maintenance and support, since just by reading the name, the purpose of the test is understood.
What challenge do you propose to improve your current tests?
- Refactor the tests you have created, testing different scenarios and possible outcomes.
- Imagine new circumstances for testing the code.
- Compare your results with the refactored project that will be available in the resources section, and share your ideas.
Contributions 4
Questions 1
Sort by:
Estructura sugerida:
test\_MétodoProbado\_escenario\_ResultadoEsperado
Ejemplo de la clase:
* Método probado: deposit
* escenario: positive amount
* resultado esperado: increase balance
test\_deposit\_positive\_amount\_increase\_balance
Organizar y nombrar pruebas de manera efectiva en Python es fundamental para asegurar que las pruebas sean fáciles de mantener, claras, y cubran adecuadamente el código que estás probando. Aquí te dejo algunas \*\*mejores prácticas\*\* recomendadas para organizar y nombrar pruebas en Python:
\### 1. \*\*Organización de las Pruebas\*\*
\#### a. \*\*Usar un Directorio Separado para las Pruebas\*\*
Es una buena práctica colocar todas las pruebas en un directorio llamado `tests/` en la raíz del proyecto. Esto ayuda a mantener las pruebas separadas del código fuente.
```
my\_project/
├── my\_app/
│ ├── module1.py
│ └── module2.py
├── tests/
│ ├── test\_module1.py
│ └── test\_module2.py
└── ...
```
\#### b. \*\*Mismo Esquema que el Código Fuente\*\*
La estructura del directorio `tests/` debe reflejar la estructura del código fuente. Por ejemplo, si tienes un archivo `module1.py` en tu código fuente, las pruebas correspondientes deberían estar en `tests/test\_module1.py`.
\#### c. \*\*Agrupar Pruebas en Clases\*\*
Utiliza clases para agrupar pruebas relacionadas. Cada clase debería agrupar pruebas de un módulo o una funcionalidad específica. De esta forma, puedes aprovechar métodos como `setUp` y `tearDown` para inicializar o limpiar datos entre las pruebas.
```python
import unittest
class CalculatorTests(unittest.TestCase):
def setUp(self):
\# Código para preparar el entorno de pruebas
pass
def tearDown(self):
\# Código para limpiar después de las pruebas
pass
def test\_add(self):
\# Prueba para la función de suma
pass
def test\_subtract(self):
\# Prueba para la función de resta
pass
```
\#### d. \*\*Un Archivo de Prueba por Módulo\*\*
Cada módulo o clase del código fuente debería tener su archivo de pruebas correspondiente. Por ejemplo, si tienes un archivo `module1.py`, crea `test\_module1.py` con las pruebas para ese archivo.
\### 2. \*\*Nombrar las Pruebas\*\*
\#### a. \*\*Nombrar Archivos de Pruebas\*\*
Los archivos de pruebas deben seguir la convención de nombrarlos con el prefijo `test\_` para que puedan ser detectados automáticamente por los frameworks de pruebas como `unittest` o `pytest`.
```bash
test\_module1.py
test\_module2.py
```
\#### b. \*\*Nombrar Métodos de Prueba\*\*
Los métodos de prueba deben comenzar con `test\_`, seguido de una descripción clara de lo que están probando. Esto asegura que las pruebas sean descubiertas automáticamente y hace que su propósito sea evidente. Utiliza nombres descriptivos para los métodos, que reflejen claramente el comportamiento que se está probando.
```python
class CalculatorTests(unittest.TestCase):
def test\_addition\_with\_positive\_numbers(self):
\# Prueba suma con números positivos
pass
def test\_division\_by\_zero\_raises\_error(self):
\# Prueba que la división por cero arroje un error
pass
```
\#### c. \*\*Descripciones Claras\*\*
Asegúrate de que los nombres de las pruebas describan el comportamiento esperado, como qué función estás probando y en qué condiciones. Evita nombres genéricos como `test\_1`, `test\_case` o `test\_function`.
\### 3. \*\*Separar las Pruebas por Tipos\*\*
\#### a. \*\*Pruebas Unitarias\*\*
Las pruebas unitarias deben centrarse en probar unidades individuales de funcionalidad (funciones o métodos). Deben ser rápidas y no depender de recursos externos (como bases de datos o APIs).
\#### b. \*\*Pruebas de Integración\*\*
En archivos separados o bajo una estructura diferente, incluye pruebas de integración que prueben cómo las diferentes partes del sistema interactúan entre sí.
```bash
tests/
├── unit/
│ ├── test\_module1.py
│ └── test\_module2.py
├── integration/
│ ├── test\_integration\_module1\_module2.py
```
\### 4. \*\*Utilizar Métodos de Configuración y Limpieza\*\*
Cuando varias pruebas comparten datos o configuraciones, utiliza métodos como `setUp`, `tearDown`, `setUpClass` y `tearDownClass` de `unittest` o los equivalentes de `pytest` para reducir la repetición de código.
```python
class DatabaseTests(unittest.TestCase):
@classmethod
def setUpClass(cls):
\# Código para configurar recursos una sola vez antes de todas las pruebas
pass
@classmethod
def tearDownClass(cls):
\# Código para liberar los recursos una vez después de todas las pruebas
pass
def setUp(self):
\# Código que se ejecuta antes de cada prueba individual
pass
def tearDown(self):
\# Código que se ejecuta después de cada prueba individual
pass
```
\### 5. \*\*Usar Nombres Descriptivos para las Clases de Prueba\*\*
Al igual que los métodos de prueba, las clases de prueba también deben tener nombres descriptivos. Los nombres deben indicar qué clase o funcionalidad están probando.
```python
class UserAuthenticationTests(unittest.TestCase):
def test\_login\_with\_valid\_credentials(self):
\# Prueba de inicio de sesión con credenciales válidas
pass
```
\### 6. \*\*Documentación y Comentarios\*\*
Incluir comentarios breves o docstrings en las pruebas puede ayudar a aclarar lo que se está probando y por qué. Esto es especialmente útil si la prueba tiene una lógica compleja o si estás probando un caso límite específico.
```python
class MathOperationsTests(unittest.TestCase):
def test\_square\_root\_of\_negative\_number\_raises\_error(self):
"""Debe generar un ValueError cuando se intenta calcular la raíz cuadrada de un número negativo"""
with self.assertRaises(ValueError):
math.sqrt(-1)
```
\### 7. \*\*Evitar Dependencias entre Pruebas\*\*
Cada prueba debe ser independiente y no debe depender de los resultados o el estado de otras pruebas. Esto garantiza que puedan ejecutarse de forma aislada, en cualquier orden.
\### 8. \*\*Ejecutar Pruebas Automáticamente\*\*
Utiliza herramientas como `pytest` o `unittest` para ejecutar las pruebas de forma automática y generar informes. Puedes integrarlas en un sistema de integración continua (CI) como Travis CI o GitHub Actions.
\### 9. \*\*Uso de Frameworks de Prueba\*\*
\- \*\*`unittest`\*\*: Es el framework de pruebas estándar en Python y tiene una buena integración con la línea de comandos.
\- \*\*`pytest`\*\*: Proporciona una sintaxis más simple y muchas características adicionales, como fixtures y el descubrimiento automático de pruebas.
\### Conclusión
Una buena organización y una convención de nombres adecuada hacen que tus pruebas sean más mantenibles y fáciles de entender. Siguiendo estas prácticas, te asegurarás de que tus pruebas sean eficaces y fáciles de trabajar a largo plazo.
***test\_deposit\_positive\_amount\_increase\_balance***
Lo del path, me quedo la duda... alguien sabe bien como es eso? a donde se puede definir el python path, y que no se haga de forma manual siempre, como lo hizo el profesor?
O existe otra forma de importar paquetes sin definir el path?
Gracias
Want to see more contributions, questions and answers from the community?