first tests#1
Conversation
vppuzakov
left a comment
There was a problem hiding this comment.
👍 для первой недели хорошо. Вмерживай и дальше по комментам развивай в следующих ПР.
| (['female'], 'she'), | ||
| (['female', 'male'], 'she') | ||
| ]) | ||
| def test_genderalize(gender, verb): |
There was a problem hiding this comment.
👍 круто, что применил параметры.
💡 давай попробуем вот что сделать - давай назовем наш тест с учетом того, какое именно поведение тестируем по следующему шаблону: test__funcname__do_something_when_something. Возможно, в процессе этого у тебя возникнет желание сделать несколько тестов (если по факту это будут разные тест кейсы).
❗ давай уберем из параметров все, что касается проверки типов - то есть tuple, int, None в gender передавать не надо. mypy нам гарантирует, что передается строка в gender всегда.
|
|
||
| def test_compose_datetime_from(): | ||
| pass | ||
| @pytest.mark.parametrize(('date_str', 'time_str', 'year', 'month', 'day', 'hours', 'minutes'), [ |
There was a problem hiding this comment.
👍 ну с одной стороны хорошо, что научился в параметрайз
❗ с другой стороны надо попробовать понять - а точно ли он тут нужен (как раз ответив на этот вопрос и столь тяжелый параметрайз скорее всего исчезнет либо совсем, либо значительно упростится)
💡 давай попробуем весь этот набор входных параметров проверить на тему - что именно в каждом из случаев мы проверяем. Возможно некоторые параметры проверяют один кейс и тогда останутся в параметрах. Некоторые проверяют уже какой-то совершенно иной кейс - и тогда должны уйти в другой тест, в названии которого обязательно надо отразить а что же это за кейс. И обрати внимание, что входные параметры (when_something) - не столь важная часть кейса, как ожидаемое поведение (do_something).
test__funcname__do_something_when_something
❗ сразу выпиливай параметры, которые пытаются делать работу за mypy - он гарантирует за то, что в функцию будут переданы нужные нам типы.
💡 закину мысль, попробуй отдельно затестить корнер кейсы по датам от времени.
| @@ -2,4 +2,4 @@ | |||
|
|
|||
|
|
|||
| def test_build_url(): | |||
There was a problem hiding this comment.
👍 хороший кейс
💡 попробуй поискать еще и если они тестируют разное поведение - отрази в названиях разных тестов это.
|
|
||
| def test_parse_ineco_expense(): | ||
| pass | ||
| assert (parse_ineco_expense( |
There was a problem hiding this comment.
💡 вот такая запись где сразу и assert, и act и arrange в один statement надо избегать, если это реально не one-line. Если это не одна строчка. Тут должно быть три полноценных раздельных шага:
- arrange (создание sms и cards)
- act (вызов parse_inecto_expense)
- assert (проверка)
❗ проверки станут значительно проще, если ты задашься вопрос - а какое поведение ты тут тестируешь? Попробуешь отразить его в названии теста. Возможно сразу возникнут несколько тестов. Например, можно тестировать что парсер правильно возвращает сумму. Отдельным тестом, что верно дата распаршена. И тд. Тогда тесты будут понятнее, явнее и значительно проще.
|
|
||
| def test_change_copy_item(): | ||
| pass | ||
| @pytest.mark.parametrize(('title', 'result'), [ |
There was a problem hiding this comment.
👍 здорово, что есть параметры
💡 не здорово, что в этих параметрах сразу разные намешаны тест кейсы. Давай выделим конкретные тест кейсы в отдельные тесты с очевидным названием по шаблону test__funcname__do_something_when_something.
💡 надо стремится, чтобы параметры были максимально простыми (никаких формул и выражений внутри)
No description provided.