Cómo encontrar errores en el código
Cómo encontrar errores en el código
Los ejemplos en este artículo están escritos en JavaScript, pero los principios son los mismos para cualquier lenguaje.
Pruebas
El código en Códica se verifica mediante pruebas automáticas. Por lo general, están escritas en el mismo idioma que el código en sí. El principio general de este tipo de prueba es bastante simple. El programa que se está probando se carga en la memoria y se llama con diferentes parámetros, mientras que las pruebas se aseguran de que su comportamiento coincida con lo esperado.
Cuando el código no pasa las pruebas, generalmente se dice que las pruebas fallaron. En este momento, comienza lo más interesante. Es necesario comprender dónde y por qué se produjo el error. Y la salida de las pruebas juega un papel clave en este proceso; es el principal asistente y guía. Pero se requiere experiencia para comenzar a sacar conclusiones correctas de lo que dicen las pruebas.
En primer lugar, es necesario clasificar el problema. Los errores en las pruebas se pueden dividir groseramente en dos categorías:
Errores que emite el compilador o intérprete: error sintáctico, error de tipado.
Afirmaciones incorrectas.
Afirmaciones
Una afirmación es una función especial que llama a tu código con parámetros específicos y verifica que devuelva el resultado esperado. Por ejemplo:
assert(isPrime(3));
assert.equal(factorial(3), 6);
Lo más importante: si las pruebas fallan en una afirmación, significa que tu código, como mínimo, se ejecutó, pero su resultado no coincide con el esperado. Y a menudo sucede que algunas afirmaciones pasan la verificación, es decir, el código devuelve el resultado correcto, y otras no, generalmente en casos límite. En última instancia, la falla de la prueba en una afirmación indica que hay un error lógico en el código.
A continuación, se muestra un ejemplo de la salida de una prueba fallida. La cantidad de detalle en la salida depende del tipo de afirmación y de las capacidades del entorno de prueba.
```plaintext
assert.js:89
throw new assert.AssertionError({
^
AssertionError: 3 == 1
at Object.<anonymous> (test.js:4:8)
at Module._compile (module.js:413:34)
at loader (/usr/local/lib/node_modules/babel-register/lib/node.js:126:5)
at Object.require.extensions.(anonymous function) [as .js] (/usr/local/lib/node_modules/babel-register/lib/node.js:136:7)
at Module.load (module.js:357:32)
at Function.Module._load (module.js:314:12)
at Function.Module.runMain (module.js:447:10)
at /usr/local/lib/node_modules/babel-cli/lib/_babel-node.js:161:27
at Object.<anonymous> (/usr/local/lib/node_modules/babel-cli/lib/_babel-node.js:162:7)
at Module._compile (module.js:413:34)
```
La salida se puede dividir en dos partes:
La primera es una descripción de lo que se esperaba de la función y lo que se obtuvo. En nuestro ejemplo, es la línea AssertionError: 3 == 1. Se lee como: "se esperaba que la función devolviera 3, pero devolvió 1". Esto ya es bueno, pero también nos gustaría ver con qué parámetros se llamó la función. Y la segunda parte de la salida nos ayudará con eso.
La segunda parte se llama backtrace y contiene una lista de funciones que se llamaron secuencialmente en el código. El orden de la salida, por lo general, es inverso: al principio, lo que se llamó por último.
En primer lugar, lo que debes hacer, comenzando desde el final, es encontrar la primera mención de la función del archivo que parece ser de prueba. Por lo general, su nombre contiene la palabra "test". En el ejemplo anterior, es at Object.<anonymous> (test.js:4:8). Entre paréntesis se indica la línea en la que se encuentra la llamada de esta afirmación. En este caso, es la línea 4.
Todo lo que queda ahora es ir al archivo correspondiente y ver cómo se llamó tu función.
Advertencias del compilador e intérprete
Errores sintácticos
El tipo más simple de errores. Este tipo de error indica que cometiste un error en la sintaxis. Olvidaste una coma, un paréntesis y cosas por el estilo. Estos errores son fáciles de encontrar y corregir. El error sintáctico se acompaña de un texto que puedes buscar en Google para encontrar posibles causas.
Otros errores
Un gran conjunto de errores que pueden ocurrir durante el desarrollo. En la salida del compilador o intérprete, siempre hay un mensaje de error que es muy importante entender. La forma más fácil de hacerlo es buscar el texto del error en Google. Recomendamos nuestra guía "Cómo buscar información técnica".
Además, los errores contienen una salida de backtrace, que te permite encontrar el lugar donde se produjo el error y tratar de analizarlo. Muchos de estos errores se pueden corregir fácilmente mediante la impresión de depuración (ver la lección de Impresión de depuración).