Autofixture: Sugerencia: siga el estilo "Organizar, actuar, afirmar" para las pruebas

Ve a por ello. Pero preferiría tener la primera letra en mayúscula, es decir

// Arrange
// Act
// Assert

en lugar de

// arrange
// act
// assert

¿Tiene fuertes razones para preferir el segundo caso?

No, las mayúsculas están bien para mí, es suficiente que usemos AAA: blush:

También puedes separar cada fase con una línea en blanco, que es el formato que uso hoy en día. Luego, el lector de prueba puede asumir que es Dado / Cuándo / Entonces , o Organizar / Actuar / Afirmar , o incluso (el de cuatro fases va aquí) .

Puede leer más sobre esto en la sección "Pruebas simples con más de tres líneas de código" aquí .

No me gusta mucho el uso de líneas vacías en lugar de comentarios en OSS y no estoy de acuerdo con la idea de Marks. Vea mi comentario aquí .

Los comentarios en la parte superior de cada fase de prueba son, básicamente, comentarios . Y en este caso particular, son disculpas , porque explican cómo , en lugar de por qué .

Ahora, de vuelta a AutoFixture, ya que todas las pruebas están decoradas con comentarios, y dado que la fase de desmontaje del AAA .

Y en este caso particular, son disculpas

Bueno, también me refiero a esta regla a menudo, sin embargo en este caso particular prefiero mantener esos "disculpas" 😄 Hacen que la estructura de la prueba sea más obvia y estricta. Personalmente, me resulta más fácil leer las pruebas "etiquetadas", pero probablemente sea simplemente una cuestión de costumbre 😉

pero probablemente eso sea simplemente una cuestión de costumbre

Esta; y quizás también una cuestión de quién escribió realmente la prueba.

Hola, me gustaría abordar esto. Soy un gran admirador de Autofixture y lo uso en mi trabajo todo el tiempo y sería una buena forma de retribuir.
Entonces, básicamente, ustedes quieren cambiar lo siguiente en todos los archivos de prueba:
// Fixture setup a // Arrange
// Exercise System a // Act
// Verify Outcome a // Assert
y finalmente // Teardown a nada.

Sí, pero tenga en cuenta que "buscar y reemplazar" podría no funcionar, ya que algunas fases se unen en algunas pruebas. Es decir, es posible que se encuentre con el sistema de ejercicio y verifique el resultado y similar, IIRC.

@moodmosaic Lo entiendo, planeo hacer archivo por archivo, no un 'buscar y reemplazar' completo, pero aún podría usarlo en los casos más obvios / simples.

Gracias,
Eissa

@moodmosaic por // Exercise system and verify outcome debería ser reemplazado por
// Act and Assert
¿O estáis pensando en algo diferente?

Por lo general, uso // Act & Assert porque se ve más conciso y genial 😎 A menos que @moodmosaic tenga preocupaciones, preferiría seguir ese estilo 😉

De cualquier manera está bien: barba de cuello:

Así que estoy tratando de comenzar con esto y, después de cargar All.sln en VS 2017, dos proyectos de F #
(AutoFoq, AutoFoqUnitTest) no se abren. Tengo experiencia zeor con F #, por lo que cualquier ayuda sería apreciada

@micheleissa Asegúrese de utilizar la última versión de VS (15.5.1 o posterior); de lo contrario, el proyecto no se abrirá (MS aplicó cambios a su F # SDK). También asegúrese de ejecutar git clean -fdx . estando en la raíz con VS cerrado. Eso es para limpiar los archivos temporales en caso de que haya revisado el proyecto antes.

Ambos pasos deberían ayudar. Avísame si no lo hicieron 😉

@zvirja Me actualicé a la última versión de VS 2017 15.5.2 y sigo enfrentando el mismo problema 😞

¿Has probado la segunda parte?

• Cerrar VS
• Echa un vistazo a las últimas master
• Vaya a la raíz y ejecute git clean -fdx .
• ¿Abrir VS de nuevo?

Parece que simplemente tiene sobras del SDK anterior.

También asegúrese de que las herramientas F # estén instaladas en su máquina:

Sí, olvidé el segundo lo siento :)
Lo intentaré ahora

@zvirja que funcionó, ¡Muchas gracias por ayudar!

Una pregunta más, ¿cómo asocio la sucursal en la que estoy trabajando en mi repositorio bifurcado a este ticket?

¡Genial que funcionó! 👍

¿Cómo asocio la sucursal en la que estoy trabajando en mi repositorio bifurcado a este ticket?

Sugeriría mirar este artículo, el flujo de trabajo está bien descrito allí: https://github.com/sevntu-checkstyle/sevntu.checkstyle/wiki/Development-workflow-with-Git : -Fork, -Branching, - Confirma, -y-Pull-Request

Básicamente, no es necesario asociar una rama con este problema. Más bien, crea una solicitud de extracción y simplemente menciona este problema en el cuerpo (por ejemplo, vea este ).

Ok lo tengo. ¡Gracias! Voy a crear la solicitud de extracción mientras trabajo en el problema para que puedan monitorear el progreso y dar comentarios de acuerdo con lo que se menciona en las pautas de contribución.