Pruebas unitarias Algunos métodos de servicio web

Question

Mi jefe quiere que cree una página .aspx, cuadros de texto para simplificar el ingreso de información de la tarjeta de crédito para que podamos probar algunos métodos en nuestro servicio de tarjeta de crédito.

Eso está bien, pero creo que podríamos hacer una prueba de Unidad para esto. Lo único es que, en lugar de escribir las cosas en un formulario web, simplemente cambiaríamos los valores variables pasados ​​a la prueba unitaria.

¿Alguien puede decirme si estamos locos por no hacer una prueba unitaria en lugar de una página .aspx para probar e ingresar datos de prueba para probar algunas llamadas a algunos de nuestros métodos?

Él terminará diciéndome que Unit Test toma demasiado tiempo para instalarse (ya que he tratado de decirle que tenemos que hacer pruebas unitarias), lo cual es una excusa estúpida.

Answer 1

me siento un poco culpable por dejar una respuesta tan simplista como lo hacía antes, así que aquí tiene una toma más en serio en él:

Vamos a examinar lo que se tardaría en prueba de la unidad del servicio. Una prueba de unidad real es una prueba automatizada que prueba una sola unidad (en su caso, sería el servicio web sin ningún sistema de back-end, como bases de datos, etc.). Como han señalado otros, es probable que la prueba unitaria adecuada del servicio sea demasiado tarde en este caso.

Eso no significa que no pueda utilizar una unidad de prueba marco (como MSTest, xUnit.net, NUnit, etc.) para conducir sus pruebas de servicio. Comparemos que escenario para el desarrollo de una página aspx de usar y tirar:

• En ambos casos Voy a asumir que el servicio web ya se ha desplegado, configurado y funcionando, debido a que probablemente sería la caso en el escenario aspx.
• En ambos casos, tendría que agregar una referencia de servicio al proyecto de prueba para generar un proxy de servicio web.
• En ambos casos tendría que escribir el código que aplica valores a los parámetros de solicitud para los métodos del servicio web.
• En ambos casos necesita invocar las operaciones del servicio web.

¿Qué es diferente?

• En el escenario aspx, deberá recopilar valores de los campos del formulario y asignar esos valores a los parámetros del método de servicio. Usando un marco de prueba, puede escribir esos valores directamente. En realidad, es más fácil escribir la prueba automatizada. 1-0
• En el caso de aspx, necesitaría escribir un código que tome los datos de respuesta y los escriba en la página web. Por el contrario, con un marco de prueba, tendrá que escribir aserciones. Yo diría que es más fácil escribir afirmaciones, pero eso es un poco subjetivo, así que lo dejo como un empate. Aún 1-0
• En el escenario de prueba automática, tendrá que escribir muchas pruebas con diferentes valores, por lo que es más código que tendrá que escribir en comparación con la opción aspx. 1-1
• Con un conjunto de pruebas automatizado, puede posteriormente ejecutar el banco de pruebas automatizadas en contra de las bases de datos muchas veces al día sin ningún esfuerzo adicional, mientras que tendría que introducir manualmente y de forma manual verificar los resultados en el escenario aspx para cada ejecución de prueba. Esa es una gran victoria en el esfuerzo de prueba. 2-1 (y eso es conservadora)

En conclusión, yo diría que si no insisten en hacer pruebas unitarias real en este caso, sino que simplemente utilizan un marco de pruebas de unidad para escribir automatizado pruebas, debería estar mejor con las pruebas automatizadas que con la página aspx. El esfuerzo de desarrollo será más o menos lo mismo.

Para su próximo proyecto, puede ver si puede usar TDD desde el principio, pero esa es otra batalla.

Buena suerte.

Answer 2

En su lugar, puede escribir una prueba simple de .NET (o Java) que llame al servicio web y verifique varios escenarios, junto con el beneficio obvio (es comprobable) también tendrá una manera automática de verificar su funcionalidad.

El tiempo "perdido" en la escritura de las pruebas unitarias será recuperado por el tiempo ahorrado al probar el mismo escenario una y otra vez en lugar de solo ejecutar las pruebas automatizadas.

Si su jefe no está convencido por ese punto le a los estudios que muestran TDD/unit tests effectiveness.

Si todo lo demás falla, ¿por qué no utilizar una herramienta automática como soapUI? Al menos se ahorrará la prueba manual de la misma funcionalidad una y otra vez.

Answer 3

Estás loco si no unidad de prueba de su servicio web en lugar de escribir un arnés de prueba manual :)

Básicamente, un servicio web es una API que se accede a través de un protocolo de control remoto, por lo que no es por unidad ¿Pruébalo?

Answer 4

En mi opinión, si crea la página .aspx y obtiene el valor del formulario web, sería más pruebas en tiempo real que las pruebas unitarias. Espero que el servicio web ya haya sido probado por la organización, que le brinda este servicio web. Creo que solo necesitas crear una forma .aspx y terminar tu trabajo.

Puede realizar pruebas unitarias para la satisfacción de su proceso de desarrollo completo. Es una buena idea que la prueba unitaria la realice la persona que escribió el código de clase/función/método web.

Avísame, si tienes alguna pregunta.

Answer 5

Si se trata de un servicio web ASMX, es posible que trate de habilitar el protocolo HttpPost en su Web.config:

<configuration> 
    <system.web> 
    <webServices> 
     <protocols> 
     <add name="HttpPost"/> 
     </protocols> 
    </webServices> 
    </system.web> 
</configuration> 

Esto permitirá a la forma de la prueba para el servicio web cuando visita la página .asmx en su navegador. Puede que no funcione bien para tipos complejos; pero si tiene tipos complejos, de todos modos será más fácil crear las pruebas unitarias que un formulario personalizado.

El argumento de que las pruebas unitarias son más difíciles que un formulario web parece incorrecto; si está desarrollando un formulario, debe escribir el código del cliente del servicio web de todos modos, además de construir la página.

Answer 6

Su jefe puede confirmar que el servicio web puede ser llamado desde un.aspx page, así como poder probar algunos valores. (¿Quiere un código de llamada de ejemplo que otra persona use para crear la página web real?) Si su servicio web llama a cualquier servicio externo y/o utiliza una base de datos, será difícil escribir pruebas unitarias automatizadas para ello.

En cuanto a escribir una prueba de unidad real para el servicio web, creo que ya ha perdido la batalla esta vez ....

La próxima vez, intente escribir pruebas unitarias para cada método que el servicio web llama, justo antes o justo después de escribir el método. No hay necesidad de decirle a su jefe que está haciendo esto, ya que dará como resultado la producción de código de trabajo más rápido.

Una vez que ha demostrado la unidad de pruebas ayudan que escribir mejor código rápidamente se puede tratar de introducir Test Driven Development y/o tener la unidad de pruebas de verificación en el sistema de control de código fuente y otras personas que se ejecuta cuando se cambiar el código

Siempre puede pasar parte de su tiempo esta noche, después de que su jefe se haya ido a casa, tratando de escribir las pruebas unitarias. Entonces solo cuéntele lo que ha hecho cuando le pregunte por qué su código no tiene errores.

Answer 7

Es una batalla que seguramente perderá. Tienes que ponerte en los zapatos de tu jefe. Hay proyectos en los que las pruebas unitarias podrían tomar demasiado tiempo, especialmente al final del ciclo de desarrollo, cuando todo se apresura para completarse. TDD tiene que seguirse desde el principio o perderá demasiado tiempo implementando pruebas unitarias después de que ya haya olvidado cómo funciona un código específico (no, los comentarios generalmente no son suficientes).

Simplemente convierta en práctica común para los próximos proyectos que realice TDD. Después de que haya probado toda su unidad de código, podría implementar algún tipo de prueba funcional con herramientas como JMeter y Selenium.

Answer 8

Supongo que ya ha perdido la batalla (lo sentimos por usted). Hay mejores soluciones que crear manualmente un consumidor para su servicio web.

Echa un vistazo SoapUI. Consume tu WSDL y te permite jugar con las solicitudes xml. Muy fácil de conectar a un servicio web para probarlo si lo único que quieren es un POC.