Conversation
| .Excluding(p => p.Parent!.Id) | ||
| .Excluding(p => p.Parent!.Weight) | ||
| .Excluding(p => p.Parent!.Parent) |
There was a problem hiding this comment.
Объясни почему выбрал именно такие проверки.
There was a problem hiding this comment.
Почему именно такая просьба, потому что если сравнить 2 этих теста, то можно увидеть что у них разная логика сравнения
There was a problem hiding this comment.
.Excluding(p => p.Parent!.Id) - данное поле у нас статический автоиндекс, как в бдшках. Его нужно исключить, одинаковые цари будут падать на нем, потому что это уникальный идентификатор
.Excluding(p => p.Parent!.Weight) - данной проверки не было в тесте, который был до рефакторинга. И поэтому решил исключить
.Excluding(p => p.Parent!.Parent) - если не исключить данное поле, то нужно будет бесконечно дописывать игнорирование поля Id в родителях. А так как мы не знаем, сколько их у нас, поэтому исключил. Также при написании теста я руководствовался логикой, что мы проверяем именно данного царя/персону, а падение теста при проверке его прародителей в данном случае будет являться неожиданным поведением
Также, если посмотреть на метод CheckCurrentTsar_WithCustomEquality, то можно заметить рекурсивный вызов, который может сильно замедлять время работы теста. И опять же действия, которые мы выполняем при рекурсии не соответствуют названию теста
There was a problem hiding this comment.
.Excluding(p => p.Parent!.Weight) - данной проверки не было в тесте, который был до рефакторинга. И поэтому решил исключить
Иногда когда ты приходишь рефачить тесты бывают баги) Я с точки зрения не вижу почему у родителя должен отличаться Weight
Также, если посмотреть на метод CheckCurrentTsar_WithCustomEquality, то можно заметить рекурсивный вызов, который может сильно замедлять время работы теста. И опять же действия, которые мы выполняем при рекурсии не соответствуют названию теста
не согласен с этим пунктом, т.к. мы если у нас будет бага на 4 или допустим 100 родителе, то у нас тест не будет выполнят свою функцию отлавливать баги
.Excluding(p => p.Parent!.Parent) - если не исключить данное поле, то нужно будет бесконечно дописывать игнорирование поля Id в родителях. А так как мы не знаем, сколько их у нас, поэтому исключил. Также при написании теста я руководствовался логикой, что мы проверяем именно данного царя/персону, а падение теста при проверке его прародителей в данном случае будет являться неожиданным поведением
попробуй посмотреть перегрузку метода Excluding
| new Func<NumberValidator>(() => new NumberValidator(precision, scale, onlyPositive)) | ||
| .Should() | ||
| .ThrowExactly<ArgumentException>(); |
There was a problem hiding this comment.
Бывают случаи когда тебе важна не факт ошибки в тесте, но и текст этой ошибки, допустим когда этот текст выводиться клиенту
| .ThrowExactly<ArgumentException>() | ||
| .Where(e => e.Message.Contains("precision")); |
There was a problem hiding this comment.
на самом делал тут тебе просто повезло, что Message содержится в обоих ошибках. Я бы явно зафиксировал текс ошибки, и там в кейсах не хватает с нулем
refactored message checking on constructor fails switched to another excluding overload to handle Id in Person
| .Excluding(p => p.Parent!.Id) | ||
| .Excluding(p => p.Parent!.Weight) | ||
| .Excluding(p => p.Parent!.Parent) | ||
| .Excluding(memberInfo => memberInfo.SelectedMemberInfo.Name == "Id") |
There was a problem hiding this comment.
Давай представим:
- что мы добавим кота, кото который будет жить вечность, и у него будет всегда будет одинаковый Id
- мы переименуем поле Id
2 participants
@Pasha0666