False: estados booleanos y lógica fiable
Publicado el · Actualizado el
False parece sencillo, pero manejar mal los estados booleanos puede romper aprobaciones, filtros, permisos, alertas y automatizaciones. Esta guía explica cómo separar false de null, cero o vacío, evitar falsos positivos y probar la lógica de forma predecible.
Definir el significado de false
Un booleano suele representar true o false, pero una respuesta negativa no es igual a un dato ausente.
Documenta qué significa true, false, null y el valor predeterminado de cada campo.
En una aprobación, false puede ser rechazo y null puede significar que aún no existe decisión.
- Definir estados
- Separar false de ausencia
- Documentar null
- Elegir defaults
Separar false de null, cero y vacío
Las condiciones amplias pueden mezclar false, cero, texto vacío y null aunque tengan significados distintos.
Usa comparaciones explícitas cuando el negocio necesite distinguirlos.
En formularios, vacío puede requerir validación mientras false puede ser una respuesta válida.
- Comparar explícitamente
- Tratar null aparte
- Conservar cero
- Validar vacío por separado
Reducir falsos positivos
Un falso positivo ocurre cuando una regla se activa sin que la condición real exista.
Define la evidencia exacta necesaria antes de que la condición sea true y evita reglas demasiado amplias.
Con Infera Agent, describe la lógica con precisión y prueba casos positivos, negativos, ausentes y límite.
- Definir evidencia
- Evitar reglas amplias
- Probar negativos
- Verificar lógica generada
Preservar false en formularios
Un control sin marcar puede omitirse del envío. La aplicación debe diferenciar no de no respondido.
Para preguntas obligatorias, opciones sí-no explícitas pueden ser más claras.
Al editar, muestra correctamente false y no la sustituyas por un valor por defecto.
- Usar sí-no explícito
- Guardar estado desmarcado
- Preservar false
- No sobrescribir
Probar filtros, permisos y paneles
Los filtros deben distinguir registros false de registros sin valor.
En permisos, false debe negar acceso mientras una configuración ausente puede requerir otro tratamiento.
Crea datos con true, false, null, cero y vacío y revisa contadores, filtros y reglas.
- Probar varios estados
- Revisar conteos
- Separar denegación de ausencia
- Usar datos representativos
Normalizar API y base de datos
Servicios externos pueden enviar booleanos como false, 0 o texto. Normaliza a un formato interno.
Valida tipos en los límites del sistema y evita conversiones ambiguas.
El valor predeterminado de una columna debe reflejar el proceso; false por defecto no es igual a null hasta decisión.
- Normalizar valores
- Validar tipos
- Elegir defaults conscientemente
- Unificar lectura y escritura
Depurar con evidencia observable
Inspecciona el valor almacenado y su tipo, no solo lo que muestra la interfaz.
Registra valor original, valor normalizado, condición y rama ejecutada.
Después de corregir, añade una prueba de regresión.
- Inspeccionar valor y tipo
- Registrar normalización
- Seguir la rama lógica
- Añadir regresión
Crear una checklist de fiabilidad
Antes de publicar, revisa cada campo booleano y confirma significado, defaults y estados permitidos.
Prueba formularios, filtros, permisos, automatización, APIs y reportes con todos los estados importantes.
La buena gestión de false preserva el significado de los datos y reduce errores de decisión.
- Revisar booleanos
- Probar estados
- Comparar UI y almacenamiento
- Mantener pruebas
Añadir pruebas de regresión específicas
Cada error relacionado con false debería convertirse en una prueba permanente. La prueba debe conservar entrada, tipo, normalización, condición y resultado esperado para detectar futuras regresiones.
Organiza las pruebas por riesgo: formularios, permisos, filtros, integraciones y automatización. Así las áreas críticas pueden revisarse rápidamente antes de publicar.
Para aumentar la fiabilidad, crea una matriz que combine estados booleanos con roles, fuentes de datos y acciones críticas. El mismo false puede funcionar bien en una pantalla y provocar un error en una automatización si cada módulo interpreta la condición de manera distinta.
Cuando varios módulos usan el mismo campo booleano, documenta un contrato sencillo sobre su significado, tipo y valores permitidos. Así formularios, APIs, base de datos, filtros y reportes comparten la misma interpretación.
Incluye también registros históricos en las pruebas. Un campo booleano nuevo puede estar vacío en datos antiguos aunque los registros nuevos siempre guarden true o false. Filtros, informes y automatizaciones deben manejar ambos grupos de forma coherente.
Durante una migración, decide explícitamente si los valores antiguos ausentes pueden convertirse en false o si deben permanecer como desconocidos. La decisión debe basarse en el significado del negocio y no solo en la comodidad técnica.
Documenta además los casos excepcionales conocidos. Si una integración externa envía representaciones especiales, normalízalas en un punto central para evitar reglas diferentes en cada módulo.
Preguntas
¿Qué es un falso positivo?
Cuando el sistema detecta o activa una condición como verdadera aunque realmente no exista.
¿False es igual a null?
No. False es un valor negativo explícito; null suele indicar ausencia, desconocido o no definido.
¿Por qué fallan los booleanos en formularios?
Campos desmarcados, valores omitidos, defaults y conversiones pueden hacer que false desaparezca.
¿Qué casos hay que probar?
True, false, null, vacío, cero, valores inválidos y límites en formularios, filtros, permisos, APIs y automatizaciones.