Autofixture: Предложение: следуйте стилю "Arrange Act Assert" для тестов.

Действуй. Но я бы предпочел, чтобы первая буква была заглавной, то есть

// Arrange
// Act
// Assert

вместо того

// arrange
// act
// assert

Есть ли у вас веские причины предпочесть второй случай?

Нет, прописные буквы мне подходят - достаточно использовать AAA: blush:

Вы также можете разделить каждую фазу пустой строкой, что я использую сейчас для форматирования. Затем читатель теста может предположить, что это Given / When / Then , или Arrange / Act / Assert , или даже (здесь идет четырехфазный) .

Подробнее об этом можно прочитать в разделе «Простые тесты с более чем тремя строками кода» здесь .

Я категорически не люблю использование пустых строк вместо комментариев в OSS и не согласен с этой идеей Marks. Смотрите мой комментарий здесь .

Комментарии в начале каждого этапа тестирования, по сути, являются комментариями . И в данном конкретном случае они приносят извинения , потому что объясняют, как, а не почему .

Теперь вернемся к AutoFixture, поскольку все тесты украшены комментариями, и поскольку фаза разборки прибора почти всегда пуста, мы можем пойти дальше и изменить их на AAA .

И в этом конкретном случае они приносят извинения

Что ж, я тоже часто обращаюсь к этому правилу, однако в данном конкретном случае я предпочитаю оставить эти «извинения» 😄 Они делают структуру теста более очевидной и строгой. Лично мне легче читать «маркированные» тесты, но, вероятно, это просто дело привычки 😉

но наверное это просто дело привычки

Этот; и, возможно, также вопрос о том, кто на самом деле написал тест.

Здравствуйте, я бы хотел заняться этим. Я большой поклонник Autofixture и все время использую его в своей работе, и это был бы хороший способ вернуть деньги.
Итак, в основном вы, ребята, хотите изменить следующее во всех тестовых файлах:
// Fixture setup в // Arrange
// Exercise System до // Act
// Verify Outcome до // Assert
и наконец // Teardown ни к чему.

Да, но имейте в виду, что выполнение «поиска и замены» может не сработать, поскольку в некоторых тестах некоторые этапы объединены. То есть вы можете встретить систему упражнений и проверить результат и тому подобное, IIRC.

@moodmosaic Я понимаю, я планирую делать файл за файлом не полный «поиск и замену», но я все равно могу использовать его в более очевидных / простых случаях.

Спасибо,
Эйсса

@moodmosaic для // Exercise system and verify outcome его следует заменить на
// Act and Assert
Или вы, ребята, думаете о другом?

Обычно я использую // Act & Assert как это выглядит более лаконично и круто 😎 Если у @moodmosaic нет проблем, я бы предпочел следовать этому стилю 😉

В любом случае все в порядке: Neckbeard:

Итак, я пытаюсь начать с этого, и после загрузки All.sln в VS 2017 два проекта F #
(AutoFoq, AutoFoqUnitTest) не открываются. У меня есть опыт работы с F #, поэтому любая помощь будет принята с благодарностью.

@micheleissa Убедитесь, что вы используете последнюю версию VS (15.5.1 или новее), иначе проект не откроется (MS внесла изменения в свой F # SDK). Также убедитесь, что git clean -fdx . запущен в корневом каталоге с закрытым VS. Это необходимо для очистки временных файлов на случай, если вы выполнили проверку проекта ранее.

Оба эти шага должны помочь. Сообщите мне, если они этого не сделали 😉

@zvirja Я

Вы пробовали вторую часть?

• Закрыть VS
• Оформить заказ на последние master
• Заходим в root и запускаем git clean -fdx .
• Снова открыть VS?

Похоже, у вас просто остались остатки предыдущего SDK.

Также убедитесь, что на вашем компьютере установлен инструмент F #:

Да, второй забыл, извините :)
Я попробую сейчас

@zvirja, которая сработала, большое спасибо за помощь!

Еще один вопрос: как связать ветку, над которой я работаю в своем разветвленном репо, с этим тикетом?

Здорово, что это сработало! 👍

как связать ветку, над которой я работаю в разветвленном репо, с этим тикетом?

Предлагаю посмотреть эту статью, там хорошо описан рабочий процесс: https://github.com/sevntu-checkstyle/sevntu.checkstyle/wiki/Development-workflow-with-Git : -Fork, -Branching, - Коммиты, -and-Pull-Request

По сути, вам не нужно связывать ветку с этой проблемой. Вместо этого вы создаете запрос на слияние и просто упоминаете об этой проблеме в теле (например, см. Этот ).

Хорошо понял. Спасибо! Я собираюсь создать запрос на перенос, пока работаю над проблемой, чтобы вы, ребята, могли следить за прогрессом и оставлять отзывы в соответствии с тем, что указано в руководящих принципах.