Mi socio comercial no quiere escribir pruebas para nuestra aplicación móvil, ya que piensa que TDD y las pruebas en general son una pérdida de tiempo. Me equivoco al discutir?

Actualización : 26/03/2017 – Podría haber leído mal. Tomé “compañero” como “mi colega”. Pero probablemente te refieres a “Mi socio – propietarios de .com”. Entonces mi siguiente es más en términos de “colega”, ambos no son dueños del negocio . Solo tenlo en cuenta para cualquiera que lo lea. Estoy de acuerdo con Alan Mellor, si ambos son copropietarios, definitivamente deberían ponerse de pie y resolverlo, y mantenerse firmes.

Mantén esto en mente. Es su derecho a TDD, no su derecho a decirle que puede o no puede . Eso incluye a su empleador, VP, CEO, PM, Lead, Manager, cualquier persona. Cree esto, y mantente en eso. Apégate a tus armas si alguien te dice que no puedes. Su elección para TDD; No es una decisión del equipo , es tu decisión. Está bien que no quieran hacerlo. Pero nadie debería decirte que no puedes. Defiende eso con todas tus fuerzas si te confrontan al respecto. Estoy dispuesto a perder mi trabajo si alguien me va a decir que no puedo hacer la prueba. Somos adultos , y esta es una profesión , no un hobby. Algunos de nosotros deseamos poder escribir código de manera segura y escribir bien el código. Esta es una de las muchas maneras de hacerlo.

No malgastes tu energía tratando de convencer a alguien que no quiere ser convencido o alguien que no está dispuesto a tener una mente abierta al respecto.

Lo que está buscando es “Sé que las pruebas funcionan”, “¿Qué debo hacer?”.

Bueno, son mis entradas:

No estoy de acuerdo con algo de lo que otros han dicho aquí (que es argumentar de inmediato) … porque yo mismo he cometido este error dos veces. Y decidí dejar de hacerlo y adoptar un enfoque diferente para manejar esta situación. En ambas ocasiones traté de discutir y conduje a una estúpida pelea, política, y no diré qué más …

Y eso es … discutir con alguien así no funciona , solo pone petróleo en el fuego.

Esto es lo que tengo que sugerirte:

  • siempre y cuando puedas hacer la prueba de tu unidad, y nadie esté tratando de detenerte, al menos estás en un lugar decente . Si bien es probable que desee que todo el equipo realice una prueba unitaria, probablemente no sucederá. Es el lugar en el que estás. Cuando la vida te dé limones (gente así), haz limonada con ella. En este caso, la limonada es, solo concéntrate en hacer bien tu trabajo, prueba y sigue adelante
  • Está bien decir que sea asertivo si tiene que estar en desacuerdo, pero deténgase allí. No discutas . Pero incluso si necesita ser firme, observe su tono … su voz y cómo está saliendo. Simplemente diga algo muy simple y breve como “haz lo que quieras, me ha ayudado muchísimo”. Perderás tu precioso tiempo. Si no deja de discutir, podría dejarlo ir porque puede volverse político si no lo hace. Literalmente aléjate. Si tienes ganas de decir algo sarcástico, levántate y ve a tomar un café.
  • La predicación excesiva puede ser arriesgada . Si predica demasiado, pueden ocurrir los mismos efectos. Reduzca su entusiasmo también por TDD. Sé que suena ridículo y apesta, pero tienes que hacerlo, hasta cierto punto, o va a funcionar en tu contra. Si alguien tiene curiosidad al respecto y le pregunta que está totalmente bien emocionarse al respecto. Pero no seas el que inicie la conversación. Deje que las personas expresen su interés, porque entonces sabe que tiene sus oídos antes de perder el aliento. Tenga cuidado también con lo que escribe en MI. Mantenga el negocio siempre, manténgalo positivo siempre , sé que a veces es difícil. IM puede dañar tu reputación tanto como verbal

He tenido que aprender eso antes de darme cuenta de que necesitaba cambiarme a mí mismo … no tratar de cambiarlos. Sí, son totalmente irracionales, sé lo difícil que es ignorar a una persona así y morderse la lengua, pero tienes que decirte a ti mismo, no vale la pena, y estar feliz de poder escribir exámenes. Todavía hay muchos lugares que literalmente te despedirán si te dicen que no escribas exámenes.

Toma en serio lo que digo aquí. Suenas apasionado Pero tienes que encontrar una manera de hacerte “feliz”.

Algunas otras cosas para mencionar:

  • Siempre hay alguien en un grupo que tiene curiosidad. Encuentra a esa persona, trabaja con ella solo por un tiempo. Conviértalos lentamente con suerte para que puedan ser tu voz en el futuro
  • Entiende que no puedes cambiar equipos enteros . Al menos no muy fácilmente. Concéntrese en mejorar sus habilidades de prueba de unidad en lugar de perder tiempo predicando o discutiendo
  • Quemar puentes puede dañar realmente tu carrera . No solía creer eso, pero después de codificar durante tanto tiempo, me doy cuenta de que esa frase es verdadera. Cuando dicen que es un mundo pequeño, la realidad es que es un mundo pequeño. La forma en que actúes ahora puede tener consecuencias más adelante … como tal vez realmente quieras trabajar para una compañía increíble, pero solo recuerdan que eras brusco, sarcástico y agresivo sobre las pruebas. Ten cuidado con cómo te encuentras. Una vez que alguien tiene una percepción de ti, eso es malo. Es casi imposible cambiar eso y ganar su confianza nuevamente. Puedes, pero en algunos casos no puedes, lo que apesta, así que no te metas en esa situación
  • Las pequeñas cosas que dices tienen enormes consecuencias. Por cada palabra sarcástica o queja, siempre hay alguien pensando en lo que acabas de decir, y tiene consecuencias, ya sea que lo sepas o no. Las personas son personas, así que debes recordar que no piensan de la misma manera que tú cuando dijiste ese comentario sarcástico

Sé donde estás. Muchos de nosotros que estamos infectados por la prueba hemos estado allí. Cuando te apasiona hacer las cosas bien, es muy difícil cambiarte y eso es exactamente lo que necesitas recordar aquí y hacerlo. No vas a cambiar a una persona como esta muy probablemente. No sé si está familiarizado con el Software Craftsmanship, pero la parte de construcción de relaciones es fundamental. Eso significa extender la rama de olivo a los “enemigos” o personas que parecen ser una pared de ladrillos. Lamento decirlo, pero incluso con los idiotas, primero debes generar confianza con ellos.

Esto es algo que las personas infectadas por las pruebas tenemos que tener siempre en cuenta y trabajar, para que podamos influir en los demás.

Os dejo con una cita de Dale Carnegie:

Si usted y yo queremos despertar un resentimiento mañana que puede afectar a las décadas y perdurar hasta la muerte, déjenos caer en una pequeña crítica, sin importar cuán seguros estamos de que está justificado.

Roy Osherove tiene una muy buena charla sobre equipos, insto a todos a verla:

Y finalmente dígales a aquellos que están interesados ​​en aprender, visite http://WeDoTDD.com 😉

A medida que su base de código crezca (y tal vez su equipo) enfrentará situaciones en las que los cambios conducen a interrupciones en otro lugar de su aplicación.

No tiene que seguir TDD en todos los aspectos. Es solo … ¿realmente quieres que tus clientes te llamen porque tu actualización de anoche rompió algo? ¿No es molesto enviar código sin saber si todo funciona bien?

Si todavía está en la fase MVP, TDD es una pérdida de tiempo. Pero una vez que tenga una buena parte de la funcionalidad que ejecuta y paga a los clientes, la gente esperará que las cosas funcionen. Aquí es donde desea implementar alguna prueba.

Especialmente para los equipos de inicio, es bueno que la incorporación obligue a un nuevo empleado a leer la base de código y escribir algunas pruebas. Cuando un nuevo miembro del equipo puede escribir una buena prueba para su aplicación, está claro que entendió lo que hace el código.

Dicho esto, no discutas demasiado sobre la prueba de manejo o no. Envíe su código, obtenga un excelente producto y pague a los clientes. De lo contrario, a nadie le importan tus pruebas.

¿Cuál es el propósito de discutir? ¿Es para que pueda continuar produciendo aplicaciones de calidad suficiente? Si es el único propósito, ¿hay alguna otra forma de lograrlo sin siquiera discutir con él?

Diría que definitivamente tiene razón para practicar TDD y, en general, tener una mentalidad de calidad. En cuanto a la pregunta, a diferencia de la mayoría de las respuestas aquí, no concluiría de inmediato si debe discutir o no.

  1. ¿Es su “socio comercial” puramente “negocio”?
  1. Si es así, no debe discutir sobre las prácticas de ingeniería, sino sobre el hecho de que puede aconsejarle, pero NO influir en CÓMO trabaja.
  2. Si tiene experiencia en desarrollo de software, debería reconsiderar seriamente su asociación. No tener una mentalidad de calidad es una bomba de tiempo para cualquier producto.
  • ¿Qué tan razonable es su socio comercial?
    1. Si se apega a su propio punto de vista al 100%, de acuerdo con el teorema de Bayes (y también el sentido común), no importa cuántos argumentos y / o evidencias esté dando, él, bueno, se mantendrá fiel a su punto.

    Tienes razón para discutir. Google “datos empíricos TDD” y ahora hay muchas pruebas para su argumento de que las pruebas reducen los errores posteriores al envío en una cantidad asombrosa (bueno, “asombroso” para cualquiera que no hace TDD!).

    El más famoso es probablemente el artículo de Microsoft de Nagappan & co.

    También te obliga a escribir un mejor código.

    Además, si su equipo alguna vez crece, no tendrán el modelo mental del código que usted tiene, por lo que sin pruebas unitarias, romperán cosas. Las pruebas unitarias son una “prueba informal” de que su código es “correcto”.

    Y ahorra trabajo. ¿Por qué probaría manualmente cualquier cosa que una computadora pueda hacer 100000x más rápido?

    ¿Alguna vez probó algún código nuevo en la línea de comandos, como en un REPL? ¡Cada vez que haces eso, hay una prueba unitaria GRITANDO para que viva! 🙂

    Además, ¿por qué una persona no técnica le dice qué hacer técnicamente?

    Voy a (nuevamente) adoptar un enfoque controvertido y decir que en una fase de inicio en la que está probando diferentes ideas, será más rápido no escribir pruebas. Sabemos que la prueba de escritura lleva más tiempo y si el código se descarta porque la idea no funciona, todavía no obtuvo el valor de las pruebas.

    Las pruebas automatizadas son excelentes para bases de código con longevidad donde se reduce el apetito por el riesgo de errores.

    Mi experiencia (desde mi inicio) es que puedes evitar escribir pruebas pero eventualmente debes escribir pruebas. Sin embargo, es un error pensar que eso significa que debe escribir pruebas desde su primer código. En mi opinión, deberías hacerlo más tarde cuando te encuentres reescribiendo o refactorizando código. Además, una vez que madure su base de código, debe comenzar con TDD, o una variedad que se adapte a su inicio / proyecto.

    Aunque esto es controvertido (especialmente en este hilo), vi a Kent Beck (autor de un famoso libro TDD y uno de los creadores de JUnit) dar una charla y dijo algo similar. Habló sobre 3X, que son tres fases en las que puede estar un proyecto: explorar, expandir y extraer. Y su descubrimiento de que los procesos son diferentes dependiendo de la etapa en la que se encuentre.

    Desde mi experiencia de inicio, encontré que lo que dijo era correcto.

    Aquí hay un video en Youtube de 3X con Kent Beck Noviembre de 2016:

    Aquí hay una página de Facebook que ha creado en “Teams in 3X”: https://www.facebook.com/notes/k

    Él es tu socio comercial. Solo escríbelos de todos modos.

    Si se queja, póngalo en su lugar. Nadie serio ya escribe software no probado.

    Es posible que pueda crear una aplicación más rápidamente sin pruebas, pero la corrección y actualización de errores más tarde puede resultar MUCHO más lenta y con errores sin las pruebas.

    Por supuesto, es posible que no esté de acuerdo con nada, pero tal vez usted pueda comprometerse, construir un MVP con pruebas mínimas y luego, si pasa la puerta Go / No-Go, agregar pruebas antes de continuar.

    Míralo de esta manera, poner frenos en tu auto lleva tiempo, pero si tienes buenos frenos, eso te permite ir mucho más rápido …

    El está equivocado. Si se pierde TDD, puede esperar más interrupciones en el código, ya que la aplicación usará / puede estar usando datos en tiempo real de sensores / gadgets.

    Escribir pruebas lo ayudará a manejar más condiciones de error, puede mostrar información significativa a los usuarios. De lo contrario, terminarás mostrando el mismo mensaje de error para todos los tipos de errores / excepciones / escenarios.

    Si opta por la idea de “probar en general es una pérdida de tiempo”, ¡predigo que su aplicación tendrá muchos problemas! Si usa TDD o no, o escribe pruebas unitarias para verificar su operación, o simplemente sufre las pruebas manuales, estará mucho mejor que sin ninguna prueba.

    Sin ninguna prueba que esté pagando, los clientes encontrarán todos sus problemas por usted. Obtendrá pésimos informes de errores (si obtiene alguno), y sus clientes se enojarán. Pero no importa, obtendrá una aplicación más rápida de esa manera, ¿verdad?

    Hay una regla: nunca probar en producción.

    Es mejor para ustedes, según él, “perder tiempo en las pruebas” que descubrir en la producción que nada funciona y que tienen que retroceder para comenzar de nuevo.

    Eso no solo desperdicia más tiempo, sino que desperdicia recursos y no se cumplen los objetivos.

    No, no estas mal.

    More Interesting

    Quiero construir un sistema de rastreo GPS. ¿Cómo obtengo los datos de latitud y longitud de un dispositivo GPS de Satellite? ¿Hay alguna API para esto? El dispositivo GPS no tiene conectividad celular o wi-fi.

    Es posible que tenga una idea para Apple que pueda convertirse en realidad, ¿a quién tendría que contactar para comenzar una cadena al escalón superior?

    ¿Soy el único purista lingüístico inglés?

    Estoy en el proceso de alinear los KPI digitales con las metas y objetivos corporativos. El aumento de la tasa de conversión en línea está en la parte superior de nuestra lista. ¿Que pasa contigo?

    Tengo una licencia de conducir en RTA m-Wallet pero no la copia impresa. ¿Será eso considerado en otros estados?

    Creo que la sinterización directa por láser de metal (DMLS) es el futuro de la fabricación. ¿Qué dices?

    No soy partidario del Congreso, pero incluso si hay una probabilidad del 1% de que el Congreso gane las elecciones de 2014, ¿qué pasará con India después de que Rahul / Sonia se convierta en primer ministro?

    Puedo inferir por qué la conservación de la energía debería ser verdadera, por supuesto, para la rendición de cuentas, pero ¿cómo se racionaliza la ley de eficiencia (también conocida como ley 2 de termodinámica)?

    Mis padres encontraron la foto de una niña que me gusta y están decepcionados. ¿Qué tengo que hacer?

    Estoy pensando en hacer un curso en SAS y R de analytixlabs. Tengo 6 meses de experiencia en SQL. ¿Qué tan útil sería el curso?