Conversation
| var saved = false; | ||
| try | ||
| { | ||
| await _orderRepository.SaveAsync(new ProposalData | ||
| { | ||
| CompanyEmail = dto.CompanyEmail, | ||
| CompanyName = dto.CompanyName, | ||
| CompanyNumber = dto.CompanyNumber, | ||
| EmployeesAmount = dto.EmployeesAmount | ||
| }); | ||
|
|
||
| saved = true; | ||
| } | ||
| catch (Exception e) | ||
| { | ||
| } |
There was a problem hiding this comment.
Вы тут немного перемудрили с try-catch и saved. Лучше отказы инфраструктуры в бизнес-логику не встраивать (как это у вас в CreateNotification сделано), а делать их "вокруг" бизнес-процесса. Т.е. в идеальной ситуации весь этот хэндлер будет обернут в трай-кетч с какой-нибудь ретрай-политикой и его инфраструктурные операторы будут идемпотентными.
При этом в самом коде будет чистое-бизнесовое:
- Если валидно - сохраняем заявку
- Если подходят условия для отправки - отправляем письмо
| } | ||
|
|
||
| [TestMethod] | ||
| public void ShouldReturnEmailDto_WhenCorrectData() |
There was a problem hiding this comment.
Не совсем бизнесовый нейминг: бизнес не знает, что такое дто. Бизнес не знает, что значит Return.
Представьте, что вы название теста транслируете вашему ПМ-у или какому-нибудь менеджеру из m1/m2. Поймут ли они перевод?
А вот если будет, например,
ShouldCreateNotification_When.. - как будто уже и понятнее
или
ShouldNotCreateNotification
ShouldFail
ShouldCreateNothing
в общем, приветствуются термины бизнеса, а не термины из языка программирования (Return/False/True/Null/etc)
| var emailDto = NotificationService.CreateNotification(notificationRequest); | ||
|
|
||
| emailDto.Should().NotBeNull(); |
There was a problem hiding this comment.
Ну тут ассертик недостаточный, но думаю, вы просто углы срезали :)
5 participants
ДЗ команды 2