Jaanis Kruumins es correcto. A un punto. Prueba todo. Todo ello. ¿Es estúpido verificar si los inits regresan correctamente o si una matriz contiene 20 elementos, si eso es lo que acabas de hacer? Sí. Pero eso lo prueba gratis, y una vez que está hecho, realmente no tiene que volverse a hacer. Probar una llamada asíncrona o la base de datos se puede hacer con datos simulados.
Pero si está agregando pruebas a un proyecto que ya está en funcionamiento, entonces estará en un mal momento. Se ha demostrado a sí mismo que no necesita pruebas, y cuando las cosas salgan mal, y lo harán, le resultará mucho más difícil saber por qué o dónde comenzar a buscar la causa raíz del error. Sin embargo, si toma esa misma base de código y la copia a otro proyecto e la importa Módulo por Módulo, descubrirá exactamente por qué necesita pruebas. Encontrará código muerto, código no utilizado. Código que se puede dividir en funciones más pequeñas y código que podría / sería mucho mejor (pero necesita esto). En cuanto a los detalles, puede probar una variedad de rangos o conjuntos de datos, o incluso que la salida no se desvía más allá de un cierto nivel de precisión. Pruebe que no puede cometer errores o que los datos de entrada que están defectuosos se manejan correctamente. Test to Fail y observe lo que falla, no solo las pruebas ‘Sunshine’
También TDD by the Test first nature te obliga a planificar y razonar tu código, no solo golpearlo hasta que esté ‘listo, supongo’
- Actualmente soy desarrollador de iOS. No sé cómo debo crecer más en esta área.
- Si actualizo mi Xcode a Xcode 8.3.1, ¿funcionará mi aplicación desarrollada en Xcode 8.2.1?
- ¿Cuál es la diferencia entre PropertyName y _PropertyName en Objective-C?
- Fui aceptado en un bootcamp de desarrollo IOS en los Estados Unidos (Make School). La matrícula es de $ 7000 excluyendo viaje + habitación + pensión. ¿Vale la pena?
- Aplicación Panorama para iOS
En cuanto a los ejemplos:
Bueno no. Y no porque sea malo, sino más bien; El código de prueba es el código menos reutilizable de todos. Pero puedo señalarle en la dirección correcta.
Esta charla es del ‘Tío Bob’ (Robert C. Martin) y se llama “Lo que mató a Smalltalk podría matar a Ruby” Y me encanta porque Smalltalk es el progenitor de Objective-C y la falta de pruebas no es lo que mató a Cocoa (Todavía no está muerto) Lo que mata a ObjC es que ES DEMASIADO fácil hacer un desastre. Pero si tiene pruebas, entonces no hará un desastre. Su código funcionará porque funciona.
