И у меня бейджик появился, хотя репозитории практически неизвестны (использую пока сам). В общем, популярность не была критерием, во всяком случае далеко не основным. Больше похоже на random.
UPD:
Чтобы заархивировать и перевести на физических носителях весь GitHub понадобилось более пяти месяцев кропотливой работы
Расслабляемся, там весь github на момент закапывания :D
Вот для этого и нужны юнит-тесты — зафиксировать поведение этих самых «кирпичиков». Чтобы если где-то в них таки довелось сделать изменение (рефакторинг), сразу было видно, не повлияло ли это на их поведение.
Тесты давно написаны. Всё работает как минимум на SQLite, MySQL и PostgreSQL. И да, все запросы это ANSI SQL, там нет каких-то продвинутых штук для которых бы еще и драйверы для каждой БД писать.
0. Это не совсем чисто Query Builder. И не надо здесь про «чистый код», мне нужен был инструмент, я его написал. Я знаю, что там не все в порядке с архитектурой, но я и цели не ставил перед собой — написать код 100% соответствующий всем нынешним хайповым трендам.
1. Я не про дисковое пространство, очевидно же.
2. Laravel для небольшого скрипта командной строки, которому дается на вход CSV и по определенным критериям тот должен дописать/обновить БД? Или для веб-страницы с тремя формами, которая нужна только на несколько раз? Вы шутите? А если сам заказчик против использования чего-то тяжеловесного (и такое бывало)?
3. Вообще-то здесь как бы про юнит-тесты спор. А Вы о чем?
В общем, конкретный пример. Есть у меня простенький самописный QueryBuilder (на PHP, пара десятков классов всего). Сложные запросы он не умеет, там надо уже SQL писать, но SELECT по какому-то полю, INSERT одной или нескольких записей, UPDATE и DELETE он умеет, — часто мне только это и нужно. Примеры (считаем, что $db уже создан, он наследует PDO):
$user = $db->users->id[12]; // получили пользователя, или null если нет
$db->users[] = [ // вставляем пользователя
'name' => $name,
'email' => $email,
'password_hash' => password_hash($password)
];
$db->users->id[12] = [ // обновляем
'name' => $anotherName
];
unset($db->users->id[12]); // удаляем
Так вот, мне надо протестировать всё это (на самом деле намного больше), для того чтобы при работе над очередным проектом не начали невовремя лезть непонятные баги. Объясните, какие тут интеграционные тесты я должен написать. Или не писать вообще? Или может таки юнит-тесты? За каждый тип запроса отвечает отдельный класс, а $db их в себе просто вызывает. И да, не советуйте мне уже существующие супернавороченные билдеры — мне не нужны пара десятков зависимостей и сотни файлов с ними впридачу.
Моя первая работа была — сборка и ремонт компьютеров (начало 2000-х). С тех пор к AMD не очень хорошее отношение (это субъективно, конечно). Летом, когда жара, много людей, которые купили компы с процессорами AMD, приходили с жалобами на частые зависания и перезагрузки. Грелись они (процессоры) конкретно. Как сейчас — не знаю.
Мне интересно, а Microsoft, Oracle, Google и прочие поменьше, тысячи их, тоже будут этой ерундой заниматься, или это только Linux напрягли? Миллиарды (да что там, триллиарды, или даже в тысячи раз больше за все время существования IT) строк кода и документации написаны, и сейчас тратить кучу времени и энергии из-за чьей-то хотелки? Не слишком ли? Может еще пройтись по художественным произведениям? Которые не исправить — запретить.
На заборе тоже много чего писали ;) Мне лично нужна абсолютная тишина, как для сна так и для работы. Со сном проще — я на одно ухо почти не слышу, так что если какие-то шумы (на улице например), то просто переворачиваюсь на тот бок, где ухо здоровое. С работой сложнее.
Я комбинирую оба подхода. Когда я уже точно знаю, что должна делать какая-нибудь функция или метод, я скорее сначала напишу пару тестов прежде чем писать реализацию.
1. Сформировать HTTP-запрос
2. Отправить в SignUpUser
3. Проверить что у нас в базе появилась запись (для тестов можно и тестовую базу иметь (имхо лучше так, я лично для своего проекта использую sqlite), или замокать класс для доступа к БД)
4. Проверить что там в message bus (надеюсь Вы интерфейсы используете, или просто хардкодите какую-то реализацию?)
5. Проверить ответ
P.S. А дальше извините, у меня работа а я и так уже три часа тут торчу.
Я отдельные модули по одному пишу. И в процессе покрываю тестами (это конечно не best practices, когда сначала пишут тесты, а потом код). Да, часть времени уходит на переписывание и тестов тоже, но дальше, когда модуль уже более-менее готов и уже может работать с другими (которые я начинаю писать, когда предыдущий почти оформился). И вот здесь тесты начинают очень помогать, так как теперь уже приходится вносить небольшие изменения в уже почти готовый код.
P.S. Это я рассказываю, как я над своим собственным проектом работаю. А заказчики как правило на тестах экономят. Но попадаются и такие, для которых тесты чуть ли не важнее кода.
На сон алкоголь влияет очень плохо — по себе знаю. Особенно если пить несколько дней подряд. Потом заснуть сложно — без алкоголя. А если продолжать, то уже и алкоголь не помогает.
Не читал (многабукаф, только пролистал) но осуждаю :) Мне лично юнит-тесты очень помогают не поломать что-нибудь, особенно когда общее представление о проекте еще не оформилось и приходится часто вносить правки. Я уверен (вернее даже знаю), что они сэкономили мне кучу времени. Другое дело, что не надо это возводить в абсолют, конечно, и стремиться к 100% покрытию или менять архитектуру в угоду тестируемости, которая может зависеть от используемого фреймворка для тестов.
UPD:
Расслабляемся, там весь github на момент закапывания :D
UPD2: Не, все же не весь.
1. Я не про дисковое пространство, очевидно же.
2. Laravel для небольшого скрипта командной строки, которому дается на вход CSV и по определенным критериям тот должен дописать/обновить БД? Или для веб-страницы с тремя формами, которая нужна только на несколько раз? Вы шутите? А если сам заказчик против использования чего-то тяжеловесного (и такое бывало)?
3. Вообще-то здесь как бы про юнит-тесты спор. А Вы о чем?
Так вот, мне надо протестировать всё это (на самом деле намного больше), для того чтобы при работе над очередным проектом не начали невовремя лезть непонятные баги. Объясните, какие тут интеграционные тесты я должен написать. Или не писать вообще? Или может таки юнит-тесты? За каждый тип запроса отвечает отдельный класс, а $db их в себе просто вызывает. И да, не советуйте мне уже существующие супернавороченные билдеры — мне не нужны пара десятков зависимостей и сотни файлов с ними впридачу.
2. Отправить в SignUpUser
3. Проверить что у нас в базе появилась запись (для тестов можно и тестовую базу иметь (имхо лучше так, я лично для своего проекта использую sqlite), или замокать класс для доступа к БД)
4. Проверить что там в message bus (надеюсь Вы интерфейсы используете, или просто хардкодите какую-то реализацию?)
5. Проверить ответ
P.S. А дальше извините, у меня работа а я и так уже три часа тут торчу.
P.S. Это я рассказываю, как я над своим собственным проектом работаю. А заказчики как правило на тестах экономят. Но попадаются и такие, для которых тесты чуть ли не важнее кода.