La mejor respuesta
Actualmente estoy trabajando para AutoTrader, que, en mi opinión, hace esto muy bien.
Simplemente te sentamos frente a una computadora portátil, con un monitor y un teclado / mouse más grandes, emparejándote con uno de nuestros desarrolladores senior y observado por un desarrollador senior diferente.
Es bastante divertido para todo el mundo, salvo los nervios habituales de las entrevistas y el hecho de que estás conociendo gente nueva. Pero ciertamente, cuando soy tu pareja, trato de tener un poco de relación amistosa, hacerte sentir bienvenido y así sucesivamente. Como lo haría normalmente. De hecho, estoy animando a que tengas éxito.
Obtienes una descripción del problema de media página de una tarea simple. Y luego haces un poco de programación en pares.
Hay varias cosas que se observan y puntúan:
- ¿Escribes pruebas primero? ¿Después del código? ¿Nunca?
- ¿Utiliza pruebas para pensar en el diseño?
- ¿Nombra las cosas claramente?
- ¿Prefiere la programación orientada a objetos, la programación procedimental, o solo una función enorme?
- ¿Interactúa bien con la pareja? ¿O incluso en absoluto?
- ¿Explica su pensamiento sobre la marcha e invita a la pareja a contribuir? ¿O sentarse en silencio?
- ¿Utiliza funciones estándar en Java, como Colecciones? Si no es así, ¿qué hace?
- ¿Utiliza bien el IDE (que es de su elección)?
- ¿Divide bien el problema? ¿Mal? ¿En absoluto?
Si puede hacer Java, TDD y / o diseño para ser probado en unidades, y parece un tipo razonablemente agradable, tiende a obtener una puntuación alta.
Esta prueba no se trata del conocimiento de características de lenguaje extraño, o conocimiento de algoritmos extraños, o incluso de terminar el problema.
Se trata de ver cómo usas estas cosas que has escrito en tu CV en la vida real.
Realmente lo disfrutarás. Les da a todos una imagen justa de dónde está un candidato.
También descarta sin piedad las afirmaciones de CV falsas.
¿Dice que hace TDD? ¿No sabes qué significa «afirmar»? Oh querido. ¿Digamos que domina la programación orientada a objetos? ¿Todo el código, que no funciona, está en el mismo método que la prueba unitaria que proporcionamos? Oh cielos.
(Y sí, eso realmente sucedió).
Para mí, ha sido una revelación estar en ambos lados de este proceso.
Respuesta
TDD es una herramienta. Lo que está mal es tratar TDD como una religión.
TDD normalmente se realiza con pruebas unitarias: pruebas de partes o funciones pequeñas («unidades» ) de su código. Se supone que las pruebas unitarias se ejecutan rápido , por lo que generalmente simula cualquier dependencia de servicio externo y solo se asegura de que se esté probando el código en sí.
El problema enorme-elefante-en-la-habitación es que a veces los servicios externos de los que se ha burlado contienen la mayor parte de la lógica de una función. Si su «unidad» toma un elemento de una base de datos mediante una consulta y lo devuelve, burlándose de que la interacción es 100\% inútil excepto como un sustituto de la verificación de tipos.
Permítanme decirlo nuevamente de una manera diferente: Los llamados “líderes de opinión ”Que predican el evangelio de TDD también predican con frecuencia el evangelio de los lenguajes dinámicos. Entonces, los idiomas que te están diciendo son mucho más productivos en realidad, requiere mucho más trabajo para probar y, a menudo, volver a escribir esas pruebas cuando necesita refactorizar.
Escriba su código en un lenguaje más seguro como C #, Java o TypeScript, y no No debe preocuparse por verificar que los tipos sigan siendo válidos. Y existen toneladas de beneficios reales al usar lenguajes de tipo estático además de no tener que escribir pruebas que en realidad no prueban nada.
Entonces, ¿qué quiero decir realmente con las pruebas «no probar nada»? Supongamos que tiene una función que realiza una consulta SQL en su base de datos. Se supone que debe buscar elementos filtrados por un campo en particular. Para escribir una prueba unitaria rápida, se burla de la consulta SQL. A menos que su biblioteca simulada realmente pueda simular toda la lógica de PostgreSQL trabajando en un conjunto de datos de muestra, la lógica del núcleo real de su función no se está probando en absoluto ; las únicas pruebas sustantivas que podría escribir para verificar la lógica solo validarían que sus simulacros arrojaban respuestas adecuadas.
Con frecuencia veo simulaciones que simplemente «verifique que la base de datos haya sido llamada la cantidad correcta de veces». ¡Eso le daría su cobertura de código del 100\%, después de todo! Genial, un número para impresionar a los gerentes no técnicos que no significa absolutamente nada en la práctica. ¡Vaya al equipo de Estadísticas engañosas!
No, lo que necesita son pruebas del sistema, o pruebas de integración / E2E, para validar que todo su sistema está trabajando. No solo pruebas unitarias, sino pruebas que no simulan las llamadas a la base de datos, sino que las realizan.Y cuando un conjunto de pruebas necesita mantener una base de datos de prueba real, limpiarla y sembrarla entre pruebas, eso hace que TDD sea una práctica poco práctica; es demasiado lento.
Así que adelante, escriba el código primero y luego escriba su prueba E2E y asegúrese de que obtenga el resultado correcto. Diablos, puede usar la función de instantánea de conjuntos de pruebas como Jesthttps: //jestjs.io/docs/en/snapshot-testing para validar simplemente que la respuesta no cambia; míralo una vez para asegurarte de que es correcto, y luego de decirle a Jest que es correcto, ¡validará que permanece igual en futuras ejecuciones! Las API se pueden probar y actualizar sus pruebas de una manera casi automática.
Entonces, si ignora los desvaríos de los fieles a TDD, puede hacer su trabajo dos veces más rápido porque no necesita esperar 10 minutos (¡o más! He visto un conjunto de pruebas que tomó más de una hora …) para que se ejecute el conjunto completo de E2E para ver que la prueba falla antes de comenzar a escribir el código.
Además, probar la interfaz de usuario en absoluto , como se indica en la respuesta de Moray Taylor, es impráctico en muchas circunstancias. Hay algún nivel de prueba E2E que se puede aplicar a la interfaz de usuario, pero en general, el retorno de la inversión rara vez parece valer la pena para el caso general.
Dicho esto, estaba trabajando en una biblioteca de gráficos una vez que estaba siendo utilizada por más de cien videojuegos diferentes, y escribí una prueba E2E suite para que valide que un cambio en la lógica interna de la biblioteca no rompería un juego oscuro que nunca había visto. Las bibliotecas siempre merecen pruebas más exhaustivas. Pero para la interfaz de usuario de una sola aplicación, las pruebas E2E casi nunca tienen sentido en mi experiencia.