Ты оптимист

Да такие ошибки х1й потом найдешь

Да такие ошибки х1й потом найдешь

+

Поэтому ребята, учите TDD

Да такие ошибки х1й потом найдешь

И чё ?)) А тикет в багтрекере висеть будет на тебе и дрочить будут тебя ))

Поэтому ребята, учите TDD

И проверяйте функцию даже на абсурдные аргументы

И чё ?)) А тикет в багтрекере висеть будет на тебе и дрочить будут тебя ))

Потом QA зае6ет, а ты даже не сможешь понять как получить эту ошибку, ибо у них есть ошибка, а у тебя нет

Сколько раз уже было такое

Поэтому ребята, учите TDD

TDD тоже не панацея

Они там раз 500 вздрочнули модуль, вылезла ошибка и показывают скрины "Каждый раз когда я то-то то-то у меня выскакивает ошибка"

TDD тоже не панацея

Ну бл*ть, ничего не панацея, но надо знать, где говно вылазит, чтобы не сидеть потом и за голову держаться

Ну бл*ть, ничего не панацея, но надо знать, где говно вылазит, чтобы не сидеть потом и за голову держаться

Или ты тратишь кучу времени на поддержку тестов, пишешь гигантские моки, а по факту... По факту это не помогло словить ни одного бага, потому слабым было совсем другое место

Этим уже QA занимается

Найти и показать

Тдд не о том, сначала пишешь тест на функцию, что от нее ждёшь, а потом функцию

Чтобы твой код работал так, как ты хочешь, не надо тут

Не говоря о том, что я больше предпочитаю функциональные тесты, в TDD тестируется один метод, и очень часто это ничего не даёт, потому что ошибкт во взаимодействии методов

Тдд не о том, сначала пишешь тест на функцию, что от нее ждёшь, а потом функцию

А у тебя функция требует огромной предварительной работы по созданию контекста, в котором она вызывается :)

И это не говоря о том, что даже сигнатура функции меняется при разработке

Тдд не о том, сначала пишешь тест на функцию, что от нее ждёшь, а потом функцию

Такое слабо работает на больших проектах

Такое слабо работает на больших проектах

Ты в больших проектах работал?

А у тебя функция требует огромной предварительной работы по созданию контекста, в котором она вызывается :)

Функцию не надо раздувать!

Ты в больших проектах работал?

AMD, разработка видеодрайверов, большой проект?

Пишите говнокод, а потом стопятьсот вариаций на вход пихать

AMD, разработка видеодрайверов, большой проект?

Я не тебе

Я не тебе

Я тоже готов подписаться, что на больших проектах TDD слабо применимо :)

Ты в больших проектах работал?

У меня проекты по 5-10 лет

Это считается большим?

Типикал крестоносцы короче

Это считается большим?

Скорее больше тысячи разрабов или меньше?

А ещё есть обращение по невыровненному указателю...

А ещё есть обращение по невыровненному указателю...

За троеточиями может скрываться что угодно. Но телепаты в отпуске.

Я с вами на счёт тестов готов до утра спорить. Не дело без тестов проект делать, не надо херню ребятам в голову пихать

https://habr.com/ru/post/309144/

Плодите говнокодеров только потому что привыкли лбом грабли ловить

Я с вами на счёт тестов готов до утра спорить. Не дело без тестов проект делать, не надо херню ребятам в голову пихать

Ты говоришь конкретно про TDD, а не про тесты

Ты говоришь конкретно про TDD, а не про тесты

У тдд полезный принцип, я не призываю весь тдд юзать

Писать тест, до функционала

Кстати, кто в такой же жопе как и я и не может работать официально, работодатель с радостью оформит вас в чёрную)

А абсолютного нуля возьмете за спасибо на подработку по вечерам? Практика нужна

У тдд полезный принцип, я не призываю весь тдд юзать

± Было бы полезно — использовалось бы чаще. На практике я такого почти не встречал. И чаще тесты пишутся после того, как под приведён в чувство. Потому что ты можешь потратить кучу времени на написание теста, а потом выяснится, что либа не поддерживает такой способ и надо делать по другому :)

Типикал крестоносцы короче

Это считается большим проектом?

± Было бы полезно — использовалось бы чаще. На практике я такого почти не встречал. И чаще тесты пишутся после того, как под приведён в чувство. Потому что ты можешь потратить кучу времени на написание теста, а потом выяснится, что либа не поддерживает такой способ и надо делать по другому :)

Так потому что в привычку это никто не ставил, когда приходит в привычку это много времени не занимает

Это считается большим проектом?

Да, молодец, но плохие практики и в крупных проектах бывают

Накопите технического долга до жопы, а потом думаете что процесс разработки так и должен проходить везде

Накопите технического долга до жопы, а потом думаете что процесс разработки так и должен проходить везде

у меня 3 проекта, 2 гпн и 1 филиал транснефти

У меня тех долг е6ать его в сраку

1 из них я веду целиком

От и до

Так потому что в привычку это никто не ставил, когда приходит в привычку это много времени не занимает

Я в другом чате обсуждал уже тему тестов, и мы пришли к выводу что написание тестов это привычка, а написание хороших - навык, поэтому не нужно пренебрегать этим, никто с рождения не пишет тесты, надо нарабатывать этот навык, чтобы очко не болело

Я в другом чате обсуждал уже тему тестов, и мы пришли к выводу что написание тестов это привычка, а написание хороших - навык, поэтому не нужно пренебрегать этим, никто с рождения не пишет тесты, надо нарабатывать этот навык, чтобы очко не болело

Для этого нанимают QA

Для этого нанимают QA

QA нанимают для сквозных e2e тестов и нагрузки, а не для юнити тестов

Да, можно написать пару тестов, чтобы убедиться в корректности алгоритма, но это максимум

Для этого нанимают QA

Кюэй должен остальные не очевидные баги искать, а не косяки в аргументах

QA нужен, чтобы ловить баги до юзера

Придумал алгоритм - он работает. QA проверяет, все ли четко работает

Придумал алгоритм - он работает. QA проверяет, все ли четко работает

Нет

Им код на х1й не нужен

Может он за вас ещё и отрефакторит код и отдебажжит, чё за бреж

Придумал алгоритм - он работает. QA проверяет, все ли четко работает

QA не проверяет алгоритм твоей функции

Так потому что в привычку это никто не ставил, когда приходит в привычку это много времени не занимает

Занимает по той причине, что надо воссоздать контекст. Например, алгоритм танцующих связей. Допустим функция шага вглубину. Чтобы написать тест, тебе надо сформировать сетку из двусвязных двунаправленных списков. Например, так https://i.imgur.com/f7z8hSa.png И ты запросто может допустить ошибку в коде, который создаёт эту сетку, поэтому тебе надо начать с теста на метод, который создаст эту сетку. И т. п.

QA не проверяет алгоритм твоей функции

Зависит о каком мы направлении разработки говорим

Зависит о каком мы направлении разработки говорим

И в каком по вашему направление QA проверяет алгоритм функции которой написал разработчик?

Зависит о каком мы направлении разработки говорим

Андерсон, прекрати сказки читать

QA не проверяет алгоритм твоей функции

Всё относительно... Если железка работает трое суток, если твоя функция вызвалась несколько миллиардов раз с разными параметрами, если фича работает так как надо, то... А писать юнит тест... Ну как минимум надо писать мок объект «ядро Linux + драйвера Quallcom»

Всё относительно... Если железка работает трое суток, если твоя функция вызвалась несколько миллиардов раз с разными параметрами, если фича работает так как надо, то... А писать юнит тест... Ну как минимум надо писать мок объект «ядро Linux + драйвера Quallcom»

Ну так юнит тест разраб пишет, а не QA, не зависимо от направления разработки

Ну так юнит тест разраб пишет, а не QA, не зависимо от направления разработки

Именно

Ну так юнит тест разраб пишет, а не QA, не зависимо от направления разработки

Я понимаю, но как ты напишешь unit-тест в такой ситуации? Допустим у тебя метод 50 строк, из них вызовы ядра Linux штук 10, и ещё штук пять обращение к драйверам Quallcom для данного конкретного чипа. Как написать unit тест для этого метода???

Я понимаю, но как ты напишешь unit-тест в такой ситуации? Допустим у тебя метод 50 строк, из них вызовы ядра Linux штук 10, и ещё штук пять обращение к драйверам Quallcom для данного конкретного чипа. Как написать unit тест для этого метода???

Судя по контексту видимо никак

И это не говоря о том, что у тебя есть несколько типов железок, которые определяются разным набором дефайнов

И в каком по вашему направление QA проверяет алгоритм функции которой написал разработчик?

Я не говорил, что QA проверяет алгоритм функции. Я говорю, они проверяют, что все работает норм и без ошибок. Если я пишу промышленный софт, например, для конструкторов, какую-то кнопку в САПРе, как QA должен понять, что она работает? Мы очень много работает с QA, они в свою очередь берут кейсы у заказчиков и мы проверяем корректность выполнения модуля, если идут какие-то вычислительные действия

Я не говорил, что QA проверяет алгоритм функции. Я говорю, они проверяют, что все работает норм и без ошибок. Если я пишу промышленный софт, например, для конструкторов, какую-то кнопку в САПРе, как QA должен понять, что она работает? Мы очень много работает с QA, они в свою очередь берут кейсы у заказчиков и мы проверяем корректность выполнения модуля, если идут какие-то вычислительные действия

Это же не unit тестирование

Это же не unit тестирование

Мы здесь уже про QA начали говорить

Это же не unit тестирование

Я говорю про бизнес-кейсы

Я заметил )) QA занимается автоматизацией тестирования, функциональным тестированием. А TDD и unit-тесты это из другой оперы

Вот ещё пример https://github.com/warmcat/libwebsockets/blob/main/minimal-examples/ws-server/minimal-ws-server-threadpool/protocol_lws_minimal_threadpool.c#L155 Напишите юнит-тест на этот метод :)

Я столько времени нахожусь в дебаге, что мне даже тесты не нужны

Я столько времени нахожусь в дебаге, что мне даже тесты не нужны

О чём я и говорил, привыкший ловить грабли лбом, против пули устоит

Я столько времени нахожусь в дебаге, что мне даже тесты не нужны

И как оно там ? Жизнь есть ?)

И как оно там ? Жизнь есть ?)

е6ано

Я заметил )) QA занимается автоматизацией тестирования, функциональным тестированием. А TDD и unit-тесты это из другой оперы

Функциональным тестированием и программист часто занимается. Например, есть скрипт, который автоматически поднимает клиент-сервер с нужными параметрами. И ты его поддерживаешь и запускаешь в разработке

О чём я и говорил, привыкший ловить грабли лбом, против пули устоит

Пусть будет так