TDD - Outside In vs Inside Out

Inside-Out y Outside-In son términos muy raros, más a menudo he escuchado / leído sobre Classic school y London school .

• Inside-Out (escuela clásica, bottom-up ): comienza a nivel de componente / clase (adentro) y agrega pruebas a los requisitos. A medida que el código evoluciona (debido a refactorizaciones), aparecen nuevos colaboradores, interacciones y otros componentes. TDD guía el diseño completamente.

• Outside-In (escuela de Londres, top-down o "TDD mockist" como lo llamaría Martin Fowler): usted sabe sobre las interacciones y los colaboradores por adelantado (especialmente aquellos en los niveles superiores) y comienza allí (nivel superior), burlándose de las dependencias necesarias. Con cada componente terminado, pasa a los colaboradores que se burlaron anteriormente y comienza con TDD de nuevo allí, creando implementaciones reales (que, aunque se utilizaron, no eran necesarias antes gracias a abstractions ). Tenga en cuenta que el enfoque afuera-en va bien con el principio YAGNI .

Ninguno de los enfoques es el único ; Ambos tienen su lugar dependiendo de lo que haces. En general, las soluciones empresariales, donde las partes del diseño provienen de arquitectos (o existen por adelantado) se podría comenzar con el enfoque del "estilo de Londres". Por otro lado, cuando se enfrenta a una situación en la que no está seguro de cómo debe verse su código (o cómo debe encajar en otras partes de su sistema), podría ser más fácil comenzar con algún componente de gama baja y dejarlo evoluciona a medida que se introducen más pruebas, refactorizaciones y requisitos.

Lo que uses, la mayoría de las veces es situacional.

Para más información, hay publicación de grupo de Google con una discusión bastante interesante sobre cómo se originó esta distinción (podría haberse originado) y por qué Londres podría no ser el nombre más apropiado.

Respuesta corta: Como de costumbre, dependerá de tus preferencias de codificación y tu enfoque de equipo.

De adentro hacia afuera la codificación es excelente porque siempre tienes algo funcionando. El inconveniente es que no necesariamente te ayuda a llegar a un lugar radicalmente diferente. Es más difícil trazar un curso de esta manera. De manera similar, escribir el código afuera en tiene el inconveniente de no tener necesariamente el beneficio de un desarrollo iterativo rápido, y no necesariamente ver todas las oportunidades y patrones que pueden surgir desde lo más profundo de la estructura del código.

He llegado a creer que ambos estilos de desarrollo son importantes y que, de hecho, es útil tener una combinación de estilos en un equipo. La idea es que de adentro hacia afuera es excelente para crear bloques de construcción, y el pensamiento externo proporciona estructura y dirección de la forma.

Parte de mi razonamiento proviene de una escuela de pensamiento muy popular que actualmente promueve el desarrollo iterativo, que a menudo es sinónimo de desarrollo de adentro hacia afuera. Creo que el desarrollo iterativo es excelente cuando no tienes demasiado para ir. Pero creo que el pensamiento global, en oposición a un proceso puramente iterativo, es invaluable para ciertos tipos de innovación y para llegar a un lugar menos obvio. Administrado adecuadamente, de adentro hacia afuera y de adentro a lado, puede ser una combinación muy efectiva.

Debes agregar Prinicples, patrones y prácticas ágiles en C # a esa lista. No sé por qué apuntó "en C #" al final. Los libros no son el idioma en absoluto y la única razón por la que no obtuvo 5 estrellas en Amazon es de personas que estaban decepcionadas por la falta de C # de sus ejemplos.

El autor, defiende que siempre que sea posible, debe intentar escribir el código de afuera hacia adentro y confiar en gran medida en el diseño evolutivo, y estoy de acuerdo con su declaración. Su razonamiento es que a medida que agregamos funcionalidad, nuestro diseño siempre evolucionará. Si comenzamos con componentes de bajo nivel a medida que se agregan funciones, nos daremos cuenta de que esos componentes no están haciendo lo que nos gustaría que hicieran, o que las cosas deben moverse. Esto podría resultar bastante costoso, especialmente si cada vez que mueve la funcionalidad de una clase a otra, debe hacer lo mismo en todos los proyectos de prueba de unidad.

Por otro lado, si usted determina qué se supone que debe hacer su aplicación en primer lugar, codifique para la interfaz externa. A medida que las funciones se agregan y el código bajo prueba aumenta de tamaño, refactoriza su aplicación en más clases, pero mientras continúa este esfuerzo de refactorización, las pruebas de unidad originales que ha escrito siguen siendo válidas. Así que empiezas completamente en el exterior y continúas refactorizando en más y más clases de bajo nivel, mientras agregas pruebas de unidades adicionales a esas clases internas, pero rara vez tendrías que moverte y volver a escribir tus pruebas de unidad.

Sin embargo, si identifica un subsistema específico de bajo nivel que su aplicación necesitará (y tal vez su compañía ya tenga la necesidad de dicho subsistema en otras aplicaciones), este sería el momento de comenzar con un componente básico de bajo nivel. Primero y luego construir la aplicación por encima de eso.

En mi opinión, el concepto de desarrollo Outside-in realmente se extiende en 2 niveles. Gerard Meszaros los describe como "afuera-en diseño " y "afuera" -in / inside-out codificación ".

• El primer nivel es un nivel de organización y proceso. El diseño de afuera hacia adentro se entiende como opuesto a arriba-abajo (cascada / taylorist) y de abajo arriba. Con un enfoque externo, nos enfocamos en la perspectiva del usuario final. Comenzamos con las pruebas de historia, las pruebas de ATDD o BDD y vamos "hacia adentro" para inferir pruebas técnicas y códigos. Por lo tanto, el diseño externo es lo que harías en un contexto ágil. Dan North tiene una gran charla sobre los enfoques de BDD, de arriba hacia abajo, de abajo hacia arriba y de afuera hacia adentro.

• El segundo nivel es técnico y tiene que ver con capas aplicativas. La codificación de entrada y salida básicamente significa comenzar desde la interfaz de usuario e ir hacia la capa central (generalmente la capa de negocios / dominio). Está pensado como opuesto a la codificación de adentro hacia afuera que comienza a partir de la capa central y codifica las capas externas en último lugar.

Por lo tanto, podría tener un diseño externo con codificación externa o externa.

Donde no estoy de acuerdo con Meszaros es cuando él asocia la codificación de adentro hacia afuera con las pruebas de integración, argumentando que en un contexto de adentro hacia afuera "no probamos el software externo de forma aislada del software interno". Pero creo que nada te impide hacerlo. Puede elegir perfectamente probar sus objetos de la capa exterior burlándose de los objetos de la capa interna, incluso si el código de producción ya existe. Solo tiene que agregar interfaces y simulacros sobre los objetos concretos existentes en lugar de escribir las interfaces, burlarse de ellas y luego crear las implementaciones más adelante, como lo haría con la codificación externa.

En otras palabras, el TDD estilo mockist o clasicista es IMO, una preocupación ortogonal a la codificación de entrada / salida. Puede utilizar perfectamente un estilo burlón junto con un enfoque de adentro hacia afuera. La razón detrás de esto es que el estilo mockist / classicist es sobre el código dependencias , mientras que la codificación de entrada / salida / salida es sobre las capas aplicativas .

Otra cosa importante es que las dependencias no son solo entre capas, sino que también existen entre objetos en la misma capa. Por ejemplo, es posible que desee comenzar con un objeto en su capa central de negocios (enfoque interno) y usar simulacros para aislar su objeto de otros objetos de la capa de negocios con los que habla. Esto sucede mucho con IoC: las abstracciones de las que depende su objeto a menudo se declaran en la misma capa, pero las implementaciones concretas están en una capa diferente.

Robert "Uncle Bob" Martin menciona brevemente la codificación de adentro hacia afuera y cómo no necesariamente entra en conflicto con una arquitectura desacoplada en su publicación " Clean Architecture ".