¿Deben las startups usar desarrollo basado en pruebas?

Cuando crea un producto de TI, normalmente puede confiar en la experiencia existente y TDD es un ejemplo comprobado para ello, por lo que puede asegurarse de que la calidad de su software estará en un alto nivel. Hay varias razones para ello:

• Al crear su producto, TDD lo ayuda a cumplir con los requisitos del producto y evitar el desplazamiento del alcance. Los desarrolladores escriben pruebas unitarias que sirven como especificaciones. Gracias a eso, tendrá un código bien escrito y podrá reestructurarlo sin esfuerzos ni pérdida de tiempo.
• Además, TDD le proporciona una prevención exhaustiva de errores. Además de las pruebas manuales, con TDD crea conjuntos de pruebas que permiten encontrar errores paso a paso mientras se produce el software. Si las suites de prueba son constantes, la calidad del software será alta.
• Debido al mantenimiento continuo y la cobertura de prueba perfecta, puede agregar o modificar funcionalidades y características a su base de código sin riesgos.

Por lo tanto, todos estos factores tienen un impacto positivo en el costo del proyecto y, como propietario de una startup, se beneficiará. Para obtener más información, consulte el artículo en el blog de RubyGarage Cómo Test Driven Development (TDD) le ayuda a reducir los costos de desarrollo

Es común escuchar la opinión expresada de que las pruebas aumentan la inversión de tiempo y el peso de la base del código, haciéndola inflexible. De hecho, siento que lo inverso es más cierto: si escribes pruebas útiles y las escribes correctamente, obligarán a tus clases a ser más flexibles para cambiar.

Esto es aún más cierto cuando se tiene en cuenta TDD, ya que es mucho menos probable que escriba código estrechamente acoplado a algunas suposiciones iniciales que pueden no ser ciertas bajo el impulso.

Por el contrario, un sistema cuyo estado final se cree que es conocido y estable a menudo fomenta el código que está estrechamente acoplado e inflexible, porque los desarrolladores no estaban pensando en su cambio con el tiempo. Pero todo el código es mutable; Todo se desvanece.

Hay una advertencia que ofrecer, por supuesto: nunca he trabajado en una startup. Pero los que he visto que no usaron pruebas unitarias y mucho menos TDD habrían obtenido muchos beneficios al hacerlo.

Las respuestas sobre esto pueden variar ampliamente, ya que se reduce en gran medida a la opinión. Así que aquí está mi punto de vista:

Pros a TDD

• Menos probabilidades de introducir errores en el código de producción. En general menos errores.
• Puede ayudar a descubrir especificaciones deficientes desde el principio antes de que comience el trabajo de implementación real.
• Va muy bien con un modelo de desarrollo más lento.

Contras:

• En mi experiencia, lleva más tiempo. Las cifras pueden variar entre 20 y 200% más. En algunos casos, el tiempo que pasé escribiendo las pruebas en realidad tomó más tiempo que escribir la implementación. Esto es discutible y está sujeto a la experiencia personal, ya que los defensores fuertes de TDD pueden argumentar que en realidad ahorra tiempo en general (debido a menos errores). Pero la inversión de tiempo inicial es ciertamente mayor con TDD.
• Puede estar reñido con las prácticas de desarrollo ágiles. Agile se trata en parte de ser flexible con un entorno de trabajo dinámico donde las especificaciones pueden cambiar y lo hacen. No es divertido escribir muchas pruebas solo para tener que rehacer una gran parte del trabajo porque la especificación cambió. En casos realmente malos de esto, los desarrolladores pueden pasar días sin lograr nada, ya que siguen reescribiendo sus pruebas. A menudo tiendo a encontrar que es más fácil adaptar una implementación existente a una nueva especificación que adaptar las pruebas existentes. A menudo, las pruebas deben reescribirse por completo.

Probablemente hay muchos otros que puedes buscar en Google. Esos son los que más me destacan.

Las startups generalmente tienen un presupuesto muy ajustado y plazos muy ajustados para cumplir con los hitos de sus inversores. Esto es rápido y, a menudo, las especificaciones no están bien definidas y pueden cambiar sobre la marcha.

Creo firmemente que debido al entorno acelerado en el que se encuentran las nuevas empresas, TDD es una muy mala elección. TDD es mucho más adecuado para empresas más grandes, mantiene productos existentes y un entorno más estático.

Sin embargo, no todas las startups son iguales. TDD podría funcionar en una startup donde tienen mucho dinero y pueden permitirse el lujo de invertir el tiempo y los recursos iniciales adicionales requeridos por TDD.

He trabajado para una startup y TDD para nosotros no fue del todo factible debido a la inversión inicial inicial que habría retrasado el lanzamiento de nuestro producto mucho más allá de lo prometido a los inversores. Lo discutimos, pero tuvimos que descartarlo. Por supuesto, esto podría significar que perdimos más tiempo después del lanzamiento del producto tratando de corregir errores. Pero esa es la vida emocionante de una startup.

Test-Driven Development es un concepto muy útil para conocer y realmente brilla en escenarios en los que tiene una buena idea de cómo se comportará una solución correcta. Por ejemplo, cuando desea implementar un protocolo bien especificado con muchos casos extremos que son difíciles de tener en cuenta.

Dicho esto, también hay escenarios en los que siento que TDD / test-first podría no producir el retorno ideal de la inversión.

Por ejemplo, cuando desea desarrollar nuevas características y está interesado principalmente en descubrir qué posibles soluciones hay para un problema. A veces puede que ni siquiera esté perfectamente claro cuál es el problema y si resolverlo es una adición valiosa al producto en el que está trabajando.

TDD no es una bala de plata. Cuidado con las personas que lo venden como aceite de serpiente. TDD es un concepto súper útil y útil en muchos escenarios. Pero como sucede con muchos conceptos y patrones de desarrollo de software, el contexto es el rey.

Creo que el enlace que publicaste responde a la pregunta mejor de lo que lo hará cualquiera aquí. Pero agregaré que TDD no es algo que hacen las empresas, es algo que hacen los desarrolladores.

Si intenta hacer que un desarrollador haga su trabajo de cierta manera, tendrá problemas. Como profesional, se debe confiar en ellos para hacer su trabajo y emplear cualquier método o técnica necesarios para lograrlo. Exigir que hagan TDD es atacar su estatus como profesional.

Está bien decir que, como equipo, nos esforzamos por lograr una cobertura de prueba del XX%, y vamos a revisar por pares todas las presentaciones de código para verificar que las pruebas hagan lo que se supone que deben hacer. Creo que TDD es una manera fácil de lograr esos objetivos, por lo que tomaré la decisión de usar TDD. Pero si alguien más puede lograr lo mismo con un proceso diferente, eso depende de ellos.

Creo que los desarrolladores deberían ser alentados a usar TDD si les conviene. Pero de cualquier manera, deberían ser responsables de su producción. Si la empresa es una nueva empresa o no, nunca tiene en cuenta eso.

La respuesta es: sí, y.

Es decir, TDD es una de las mejores prácticas de ingeniería. Y, los equipos que lo hacen mejor entienden cómo puede ser poderoso y lo que puede hacer que te frene.

Para MVP
El objetivo es conseguir algo rápido y sucio para saber si tiene un producto / mercado adecuado.

– use TDD estratégicamente
– no use TDD el 100% del tiempo solo ‘porque’, úselo cuando tenga más sentido para el objetivo de aprender si su MVP tiene piernas

Para el código MVP posterior
Aquí el objetivo es crear una base sólida que se pueda construir en el futuro.

– use TDD como práctica predeterminada, ya sea el 100% del tiempo o tan cerca como pueda

Sí, es dolor a corto plazo para ganancia a largo plazo.

El inicio debe funcionar en una de las metodologías ágiles, sin embargo, debe ajustarse estrictamente al concepto de historia ‘Definición de listo’ y ‘Definición de hecho’.

La definición de Listo es donde BA / Dev / Test y el Propietario del Negocio o Producto acuerdan de qué trata la historia y sus criterios de aceptación.

Los mejores criterios de aceptación por escrito ayudan a escribir mejores casos de prueba de unidad / integración / regresión, lo que puede ser doloroso para comenzar, sin embargo, a medida que construye el producto, su confianza crece en lo que se construye.

Me encontré haciendo la misma pregunta. Mientras aprendía (o intentaba aprender) el código base y la funcionalidad, TDD realmente me confundió. Fui a la guía de rieles, la descargué en mi Kindle y construí su aplicación sin todo el código de prueba adicional. Aprendí el código.

Una vez que uno conoce el código y comprende las relaciones, entonces TDD tiene sentido. Como declaró Ethan, TDD le permite reescribir y modificar con confianza que su conjunto de pruebas mantendrá la funcionalidad básica.

Personalmente, no estoy seguro de que enseñar una nueva suite de desarrollo (Rails) con TDD sea una buena idea.

Fuentes utiles
Anadea
Introducción al desarrollo guiado por pruebas (TDD)

¿Por qué no deberían? La práctica humana lo hace! Y definitivamente hay otros.