M
по-моему я рассказываю это в бесплатном
Не, ему лучше продать
Size: a a a
2020 November 16
DO
Samvel Osipyan
3. к какому коду кто должен иметь ? если человек авто-тестер он сам понимает как тестирвоать исходя из моих первых двух ответов
все хорошо и правильно, только вы описываете не юнит, а интеграционные тесты. Все хорошо, просто не называйте их юнитами, юнит-тесты - это другое, юнит от слова мельчайшая единица.
DO
если вам на собеседовании загоняют что это юнит-тесты - в целом, это повод не идти в эту компанию, потому что она не разбирается в элементарной терминологии.
SO
Пожалуйста
- потому что он должн знать КОД модуля идеально. Каждого, на который пишет юнит
- он должен иметь возможность его прогонять, это не происходит на тестовом стенде во время работы системы
- он должен иметь доступ к этому коду. А может не иметь.
- он должен поправлять его в тот же момент, когда разработчик коммитит код. Код должен быть закоммичен вместе с юнит-тестом. В идеале - юнит-тесты должен быть написан до кода модуля, что непросто сделать, не зная что хочет разработать разработчик вместе с архитектурой системы
- это нерентабельно. Разработчику на свой код написать тест пять минут, новому человеку в этот код надо вникнуть. В чужой код.
- потому что он должн знать КОД модуля идеально. Каждого, на который пишет юнит
- он должен иметь возможность его прогонять, это не происходит на тестовом стенде во время работы системы
- он должен иметь доступ к этому коду. А может не иметь.
- он должен поправлять его в тот же момент, когда разработчик коммитит код. Код должен быть закоммичен вместе с юнит-тестом. В идеале - юнит-тесты должен быть написан до кода модуля, что непросто сделать, не зная что хочет разработать разработчик вместе с архитектурой системы
- это нерентабельно. Разработчику на свой код написать тест пять минут, новому человеку в этот код надо вникнуть. В чужой код.
4. юТесты можно писать по тест кейсам, а значит можно и не дожидаться реализации разрабов, другое дело тогда как локаторы писать
5. объеденяем п. 1-4 и становится всё рентабельно, потому что не надо писать на каждый фикс юТест если он уже заранее написан
5. объеденяем п. 1-4 и становится всё рентабельно, потому что не надо писать на каждый фикс юТест если он уже заранее написан
DO
Samvel Osipyan
4. юТесты можно писать по тест кейсам, а значит можно и не дожидаться реализации разрабов, другое дело тогда как локаторы писать
5. объеденяем п. 1-4 и становится всё рентабельно, потому что не надо писать на каждый фикс юТест если он уже заранее написан
5. объеденяем п. 1-4 и становится всё рентабельно, потому что не надо писать на каждый фикс юТест если он уже заранее написан
ютесты НЕЛЬЗЯ писать по тест-кейсам.
DO
вы ошиблись уже в первый двух пунктах ответа. Это - интеграционные тесты. Пожалуйста, прочитайте определение.
DO
вернее не, можно писать по тест-кейсам, кто мешает-то. Только это тест-кейсы, которые никогда не проходятся руками, никогда, это фактически невозможно, их проще написать сразу кодом, чем сначала описать словами. Разработчику ))))
SO
все хорошо и правильно, только вы описываете не юнит, а интеграционные тесты. Все хорошо, просто не называйте их юнитами, юнит-тесты - это другое, юнит от слова мельчайшая единица.
понял, возможно я напутал с определениями, но в моём понимании юниты это много-много мелких тестов которые потом покрывают всю задачу
DO
Samvel Osipyan
понял, возможно я напутал с определениями, но в моём понимании юниты это много-много мелких тестов которые потом покрывают всю задачу
да, мелких, просто еще более мелких ) еще более прям в коде 🙂 Именно поэтому их пишут разработчики. А так все верно.
И
Не понял вопрос, прости.
Помнишь мы обсуждали какие есть техники тест-дизайна, какое определение какого-то вида тестирования считается правильным из пяти разных источников, каждый из которых говорит разные вещи об одном и том же виде? Вот раскрыть для новеньких в тестировании эту тему, чтобы они понимали почему в разных источниках информация отличается и что с этим делать.
SO
да, мелких, просто еще более мелких ) еще более прям в коде 🙂 Именно поэтому их пишут разработчики. А так все верно.
яж говорил с самого начала что мы говорим об одном и томже но с разных углов ))
NB
разрабов заставить писать тест кейсы и баг репорты по юнит тестам :D
А
Samvel Osipyan
можете четко сказать почему авто-тестер QA не пишет юТесты ?
Потому что юнит тесты - для разрабов.
- дисциплинируют разработку - недостаточно написать код кое как, нужно покрыть его тестами. Когда разраб пишет тесты - он обдумывает поведение фичи или компоненты более детально с точки зрения корнер кейсов, и может найти потенциальный баг (или вообще косяк логики) еще до коммита. На этом к слову основывается TDD, где сначала пишет тесты, а потом предусмотрев значительную часть кейсов - уже пишут фичу.
- юнит тесты дают наиболее быстрый фидбек по изменению, соответственно цена дефекта минимальна
- некоторые эффективно можно проверить только юнитами
QA максимум участвуют ввиде ревью тесткейсов, чтобы улучшить покрытие юнитами фичей, и не допустить лажи типа фэйковых тестов.
- дисциплинируют разработку - недостаточно написать код кое как, нужно покрыть его тестами. Когда разраб пишет тесты - он обдумывает поведение фичи или компоненты более детально с точки зрения корнер кейсов, и может найти потенциальный баг (или вообще косяк логики) еще до коммита. На этом к слову основывается TDD, где сначала пишет тесты, а потом предусмотрев значительную часть кейсов - уже пишут фичу.
- юнит тесты дают наиболее быстрый фидбек по изменению, соответственно цена дефекта минимальна
- некоторые эффективно можно проверить только юнитами
QA максимум участвуют ввиде ревью тесткейсов, чтобы улучшить покрытие юнитами фичей, и не допустить лажи типа фэйковых тестов.
DO
Samvel Osipyan
яж говорил с самого начала что мы говорим об одном и томже но с разных углов ))
ну так я с самого начала говорила, что не незывайте просто их юнит-тестами, а то люди читают совсем не то, что вы хотите сказать )
SO
ну так я с самого начала говорила, что не незывайте просто их юнит-тестами, а то люди читают совсем не то, что вы хотите сказать )
ок, буду говорить "много-много мелких тестов" )
DO
Samvel Osipyan
ок, буду говорить "много-много мелких тестов" )
аххаха, 👍.
кстати, еще атомарными их называют.
кстати, еще атомарными их называют.
SO
Потому что юнит тесты - для разрабов.
- дисциплинируют разработку - недостаточно написать код кое как, нужно покрыть его тестами. Когда разраб пишет тесты - он обдумывает поведение фичи или компоненты более детально с точки зрения корнер кейсов, и может найти потенциальный баг (или вообще косяк логики) еще до коммита. На этом к слову основывается TDD, где сначала пишет тесты, а потом предусмотрев значительную часть кейсов - уже пишут фичу.
- юнит тесты дают наиболее быстрый фидбек по изменению, соответственно цена дефекта минимальна
- некоторые эффективно можно проверить только юнитами
QA максимум участвуют ввиде ревью тесткейсов, чтобы улучшить покрытие юнитами фичей, и не допустить лажи типа фэйковых тестов.
- дисциплинируют разработку - недостаточно написать код кое как, нужно покрыть его тестами. Когда разраб пишет тесты - он обдумывает поведение фичи или компоненты более детально с точки зрения корнер кейсов, и может найти потенциальный баг (или вообще косяк логики) еще до коммита. На этом к слову основывается TDD, где сначала пишет тесты, а потом предусмотрев значительную часть кейсов - уже пишут фичу.
- юнит тесты дают наиболее быстрый фидбек по изменению, соответственно цена дефекта минимальна
- некоторые эффективно можно проверить только юнитами
QA максимум участвуют ввиде ревью тесткейсов, чтобы улучшить покрытие юнитами фичей, и не допустить лажи типа фэйковых тестов.
а тогда авто-тестеры чем заниматься должны, как называется то что они пишут после @Test ?
А
Samvel Osipyan
а тогда авто-тестеры чем заниматься должны, как называется то что они пишут после @Test ?
а что вам на курсах говорили на эту тему? :)
SO
а что вам на курсах говорили на эту тему? :)
ничего, вот и спрашиваю поэтому)
А
Samvel Osipyan
ничего, вот и спрашиваю поэтому)
Интересные курсы :)