Autofixture: Sugestão: siga o estilo "Arrange Act Assert" para os testes

Vá em frente. Mas eu prefiro ter a primeira letra maiúscula, ou seja

// Arrange
// Act
// Assert

ao invés de

// arrange
// act
// assert

Você tem fortes motivos para preferir o segundo caso?

Não, maiúsculas estão bem para mim - basta usarmos AAA: blush:

Você também pode separar cada fase com uma linha em branco, que é a formatação que uso atualmente. Então, o leitor de teste pode assumir que é Dado / Quando / Então , ou Organizar / Agir / Assertar , ou mesmo (o de quatro fases vai aqui) .

Você pode ler mais sobre isso na seção "Testes simples com mais de três linhas de código" aqui .

Não gosto muito do uso de linhas vazias em vez de comentários no OSS e discordo dessa ideia de Marks. Veja meu comentário aqui .

Os comentários sobre cada fase de teste são, basicamente, comentários . E, neste caso específico, são desculpas , porque explicam como - em vez de por quê .

Agora, de volta ao AutoFixture, já que todos os testes são decorados com comentários, e como a fase de desmontagem do AAA .

E, neste caso particular, são desculpas

Bem, também me refiro a essa regra com frequência, porém, neste caso particular, prefiro manter aquelas "desculpas" 😄 Elas tornam a estrutura do teste mais óbvia e rígida. Pessoalmente, acho mais fácil ler testes "rotulados", mas provavelmente isso é simplesmente uma questão de hábito 😉

mas provavelmente isso é simplesmente uma questão de hábito

Esse; e talvez também uma questão de quem realmente escreveu o teste.

Olá, eu gostaria de resolver isso. Sou um grande fã do Autofixture e uso-o no meu trabalho o tempo todo e seria uma boa forma de retribuir.
Então, basicamente, vocês querem alterar o seguinte em todos os arquivos de teste:
// Fixture setup a // Arrange
// Exercise System a // Act
// Verify Outcome a // Assert
e finalmente // Teardown a nada.

Sim, mas lembre-se de que 'localizar e substituir' pode não funcionar, pois algumas fases são unidas em alguns testes. Ou seja, você pode encontrar Sistema de exercícios e verificar resultados e similares, IIRC.

@moodmosaic eu entendo, estou planejando fazer arquivo por arquivo não um 'localizar e substituir' completo, mas ainda posso usá-lo nos casos mais óbvios / simples.

Obrigado,
Eissa

@moodmosaic por // Exercise system and verify outcome deve ser substituído por
// Act and Assert
Ou vocês estão pensando em algo diferente?

Normalmente eu uso // Act & Assert porque parece mais conciso e legal 😎 A menos que @moodmosaic tenha dúvidas, prefiro seguir esse estilo 😉

De qualquer maneira, está tudo bem: neckbeard:

Estou tentando começar com isso e depois de carregar o All.sln no VS 2017, dois projetos F #
(AutoFoq, AutoFoqUnitTest) estão falhando ao abrir. Tenho experiência zero com F #, então qualquer ajuda seria apreciada

@micheleissa Certifique-se de usar a versão mais recente do VS (15.5.1 ou posterior), caso contrário, o projeto não será aberto (a MS aplicou alterações em seu F # SDK). Certifique-se também de executar git clean -fdx . como root com o VS fechado. Isso é para limpar os arquivos temporários, caso você tenha feito check-out do projeto anteriormente.

Essas duas etapas devem ajudar. Me avise se não 😉

@zvirja Eu atualizei para a versão mais recente do VS 2017 15.5.2 e ainda enfrento o mesmo problema 😞

Você já tentou a segunda parte?

• Fechar VS
• Confira o último master
• Vá para o root e execute git clean -fdx .
• Abrir o VS novamente?

Parece que você simplesmente tem sobras do SDK anterior.

Certifique-se também de que as ferramentas F # estejam instaladas em sua máquina:

Sim, esqueci o segundo, desculpe :)
Vou tentar agora

@zvirja que funcionou, Muito obrigado pela ajuda!

Mais uma pergunta, como associo o branch no qual estou trabalhando em meu repo bifurcado a este tíquete?

Ótimo que funcionou! 👍

como associo o branch no qual estou trabalhando em meu repo bifurcado a este tíquete?

Eu sugiro que você dê uma olhada neste artigo, o fluxo de trabalho está bem descrito lá: https://github.com/sevntu-checkstyle/sevntu.checkstyle/wiki/Development-workflow-with-Git : -Fork, -Branching, - Commits, -and-Pull-Request

Basicamente, você não precisa associar um branch com este problema. Em vez disso, você cria uma Solicitação Pull e simplesmente menciona esse problema no corpo (por exemplo, veja este ).

OK, entendi. Obrigado! Vou criar a solicitação pull enquanto trabalho no problema para que vocês possam monitorar o progresso e dar feedback de acordo com o que foi mencionado nas diretrizes de contribuição.