Они также меняются, как того требует структура проекта. Если у вас только что созданный проект, то да, написание юнит-тестов нужно отложить до момента, когда проект более менее устаканится. В ином случае вы будете тратить тонну времени на изменение тестов не по причине добавления/изменения функциональности, а из-за рефакторинга. А в устоявшемся проекте изменение тестов происходит в рамках выполнения задачи за вменяемое время.
Зачем нужен тест, которому я заранее говорю, что будет на выходе, а потом проверяю, что на выходе именно это?
Вы не говорите в тестах проверяемому методу, что надо вернуть. Вы говорите классам/объектам, которые вызываются в тестах, что надо вернуть. Тем самым вы проверяете только работу проверяемого метода. А результат работы метода, если он есть, сравнивается с ожидаемым значением.
Большая часть юнит-тестов проверяет только количество вызовов при разных вызовов, а не данные.
Это возможно, если у вас большая часть void методов. На практике это не частое явление. А так для проверки, на вскидку, есть:
Возвращаемое значение
Выбрасываемые ошибки
Кол-во вызовов методов
Проверка того, что какой-то метод не вызывался
Интеграционные делают всю основную работу тестирования и служат гораздо более яркими лампочками - и в гораздо меньших количествах, не перегружая мозг, - чем юнит.
Зависит от того, кто и для каких целей пишет. Основной инструмент тестирования разработчика ⟶ юнит-тесты. Мы проверяем только свой код, мокая всё остальное. Запускаются и проходят эти тесты также сильнее быстрее (не забываем, что для интеграционных нужно поднимать всю инфру) А вот тестировщика основным инструментом являются интеграционные тесты, так как задача у тестировщика другая.
Большое количество юнит-тестов сильно замедляет деплой, сиди и жди, пока они все пробегут.
Если юнит-тесты проходят дольше интеграционных (это надо сильно сильно постараться), то такие тесты написаны неправильно. С другой стороны, куда-то торопитесь? 5 минут времени критично?
Ваш СТО всё прекрасно знает и понимает, и работает на свои KPI. Он получит премии за это и уйдёт на другой проект. Автор, ты не привык к закулисным играм, которыми заняты люди на подобных должностям, поэтому тяжело противодействовать: нет понимания того, как это можно сделать, ведь ты не этим занимаешься в работе.
Либо борись в этим, используя грязные способы, либо делай вид, что ты согласен со своим СТО, давай ему минимум, необходимы для того, чтобы оставаться на работе, а сам делай своё дело.
У вас разные приоритеты. Ты за красоту, чистоту и правильность, а он за KPI.
Может быть ещё надо степень получить, чтобы Обсидианом начать пользоваться? Господа, есть люди, которые используют самый базовый функционал, и этого хватает за глаза. (15 минут чтения). Но всегда найдётся увлечённый человек, который расскажет, что перед использованием надо прочитать, понять, запомнить талмуд рекомендаций. Спасибо, не надо.
Так вот, контекстами общаются в основном восточно-европейские разработчики (РФ, РБ, Польша, Сербия, Словакия, Венгрия). Американцы и европейцы начиная с Австро-Германии редко проводят общение с контекстом и предпочитают подробно расписывать всё, как для человека, который вчера пришел на проект. И это долго, реально долго.
А потом ты попадаешь в ситуацию, когда действительно только пришёл на проект, а задачи формулируются типа: "Не работает вот эта штука в таком-то сервисе". И сидишь тратишь время на то, чтобы понять, что он тебя нужно, что хотят в итоге, где это вообще находится, лишнее общение с тем, кто завёл задачу.
Конечно, в этом нужен баланс, но вот читать описание задач, общение в PR, документацию, где люди общаются контекстами - это та ещё радость. Им, конечно, удобно, а тем, кто придёт после них?
Редко мы думаем над тем, насколько просто будет разобраться тем, кто придёт после. Общение в личках, описание таски в виде контекста и т.д. А ты потом пытаешься что-то отыскать и понять, но сделать это можно только найдя кого-то через пятые руки, попутно подождав полдня ответа от каждого из цепочки.
Если хотите заслужить уважение — работайте больше положенного.
Больше всех в колхозе работала лошадь, но председателем она так и не стала.
Так повелось, что когда у меня заканчивались задачи, я всегда придумывал, чем заняться в проекте. Это происходило не потому, что я стахановец по натуре, а из-за страха остаться без работы.
Так причина ваших овертаймов в страхе уволнения, а не потому, что если работать нормально, то вас уволят.
Какой адекватный менеджер даст джуну на испытательном сроке сложную задачу с жёстким дедлайном? Или автор приукрашивает, или менеджер плохо понимает, что делает, но это уже не вина разработчика.
Моё поведение на испытательном сроке было примерно таким же, как у автора, потому ряд советов:
НЕ работайте больше положенного без оплаты. Если вы не ставите менеджера в известность, что перерабатываете, то он считает, что вы так всегда работаете => выполняете большой объём задач за рабочий день. Когда вы в последующем решите работать в рамках рабочего дня, то ваш менеджер будет неприятно удивлён вашей продуктивности. Не говоря уже про выгорание, которые не заставит себя ждать
Ведите себя естественно. Вам в этой компании ещё работать. Если вы будете на испытательном сроке изображать из себя очень общительного и активного человека, то опять же, все будут в недоумении, когда это прекратится.
Отстаивайте свои интересы и границы даже если вы, о боже, на испытательном сроке. Ваш менеджер и вы привыкнете к тому, что с вашими мнением можно не считаться, а это чревато.
Они также меняются, как того требует структура проекта.
Если у вас только что созданный проект, то да, написание юнит-тестов нужно отложить до момента, когда проект более менее устаканится. В ином случае вы будете тратить тонну времени на изменение тестов не по причине добавления/изменения функциональности, а из-за рефакторинга.
А в устоявшемся проекте изменение тестов происходит в рамках выполнения задачи за вменяемое время.
Вы не говорите в тестах проверяемому методу, что надо вернуть.
Вы говорите классам/объектам, которые вызываются в тестах, что надо вернуть. Тем самым вы проверяете только работу проверяемого метода.
А результат работы метода, если он есть, сравнивается с ожидаемым значением.
Это возможно, если у вас большая часть void методов. На практике это не частое явление.
А так для проверки, на вскидку, есть:
Возвращаемое значение
Выбрасываемые ошибки
Кол-во вызовов методов
Проверка того, что какой-то метод не вызывался
Зависит от того, кто и для каких целей пишет.
Основной инструмент тестирования разработчика ⟶ юнит-тесты. Мы проверяем только свой код, мокая всё остальное. Запускаются и проходят эти тесты также сильнее быстрее (не забываем, что для интеграционных нужно поднимать всю инфру)
А вот тестировщика основным инструментом являются интеграционные тесты, так как задача у тестировщика другая.
Если юнит-тесты проходят дольше интеграционных (это надо сильно сильно постараться), то такие тесты написаны неправильно.
С другой стороны, куда-то торопитесь? 5 минут времени критично?
Ваш СТО всё прекрасно знает и понимает, и работает на свои KPI. Он получит премии за это и уйдёт на другой проект.
Автор, ты не привык к закулисным играм, которыми заняты люди на подобных должностям, поэтому тяжело противодействовать: нет понимания того, как это можно сделать, ведь ты не этим занимаешься в работе.
Либо борись в этим, используя грязные способы, либо делай вид, что ты согласен со своим СТО, давай ему минимум, необходимы для того, чтобы оставаться на работе, а сам делай своё дело.
У вас разные приоритеты. Ты за красоту, чистоту и правильность, а он за KPI.
Может быть ещё надо степень получить, чтобы Обсидианом начать пользоваться?
Господа, есть люди, которые используют самый базовый функционал, и этого хватает за глаза. (15 минут чтения).
Но всегда найдётся увлечённый человек, который расскажет, что перед использованием надо прочитать, понять, запомнить талмуд рекомендаций. Спасибо, не надо.
А потом ты попадаешь в ситуацию, когда действительно только пришёл на проект, а задачи формулируются типа: "Не работает вот эта штука в таком-то сервисе". И сидишь тратишь время на то, чтобы понять, что он тебя нужно, что хотят в итоге, где это вообще находится, лишнее общение с тем, кто завёл задачу.
Конечно, в этом нужен баланс, но вот читать описание задач, общение в PR, документацию, где люди общаются контекстами - это та ещё радость. Им, конечно, удобно, а тем, кто придёт после них?
Редко мы думаем над тем, насколько просто будет разобраться тем, кто придёт после. Общение в личках, описание таски в виде контекста и т.д.
А ты потом пытаешься что-то отыскать и понять, но сделать это можно только найдя кого-то через пятые руки, попутно подождав полдня ответа от каждого из цепочки.
Больше всех в колхозе работала лошадь, но председателем она так и не стала.
Так причина ваших овертаймов в страхе уволнения, а не потому, что если работать нормально, то вас уволят.
Какой адекватный менеджер даст джуну на испытательном сроке сложную задачу с жёстким дедлайном?
Или автор приукрашивает, или менеджер плохо понимает, что делает, но это уже не вина разработчика.
Моё поведение на испытательном сроке было примерно таким же, как у автора, потому ряд советов:
НЕ работайте больше положенного без оплаты.
Если вы не ставите менеджера в известность, что перерабатываете, то он считает, что вы так всегда работаете => выполняете большой объём задач за рабочий день.
Когда вы в последующем решите работать в рамках рабочего дня, то ваш менеджер будет неприятно удивлён вашей продуктивности.
Не говоря уже про выгорание, которые не заставит себя ждать
Ведите себя естественно. Вам в этой компании ещё работать.
Если вы будете на испытательном сроке изображать из себя очень общительного и активного человека, то опять же, все будут в недоумении, когда это прекратится.
Отстаивайте свои интересы и границы даже если вы, о боже, на испытательном сроке.
Ваш менеджер и вы привыкнете к тому, что с вашими мнением можно не считаться, а это чревато.