- 1
- 2
- 3
- 4
var usr = Enumerable.Range(1, 1)
.Select(id => new User(1, "FooBar", "desc" + 1, DateTime.UtcNow))
.ToReadonly()
.GetRandomElement();
Си диез / Говнокод #12260
0
Из юнит-теста. Копипаста рождает чудовищ.
Запостил: 
VasyaMatros,
(Updated )
Тесты используют в качестве источника данных ин-мемори рид-онли коллекции и выбирают оттуда рандомом. Кому-то захотелось кастома, герой скопипастил кусок кода из стора, подкрутил согласно нуждам и, вероятно, был очень доволен, что цель достигнута без применения мозга.
а после еще пары тысяч вывереных тест-кэйсов приходит и просвещение: копи-паст это очень хорошо, все руками писать - плохо. потому что копи-пастом меньше глупых очепяток делается. и если находится ошибка, то ее простой заменой в редакторе можно пофиксить - сразу во всех тест-кэйсах.
Проблема не в опечатках, а в "недопечатках", когда пропускаешь места, где нужно внести изменения. И именно поэтому нужно не копипастить, а выделять похожие участки кода в отдельные функции/классы.
DRY, motherfucker!
Это значит вы неправильно копипастите.
Шучу, случается. 🙂
> И именно поэтому нужно не копипастить, а выделять похожие участки кода в отдельные функции/классы.
Применение традиционных методов хорошего программирования (продуманый дезайн, правильно модулировано, хорошо структурировано) к тест-кэйсам имеет один убийственных недостаток: реализация тест становится сложным, и требует своего собственного теста. Тупая структура тест кэйсов есть часто желаемый эффект, что бы не уподоблятся тестируемой программе.
Ну да я думаю у каждого опыт свой.
По мне, так гораздо хуже иметь километры почти одинакового кода, чем несколько вызовов методов с понятными именами. Отлаживать такие тесты тоже гораздо проще - каждое действие производится только в одном участке кода.
И, кстати, сложные тесты могут быть признаком сложного кода - если код состоит из огромных кусков, то и тесты будут такими же. Для этого и придумали CRAP-метрику.
http://googletesting.blogspot.ru/2011/02/this-code-is-crap.html
При тестировании в PHP на PHPUnit меня больше всего убивает не сложность тестов, а непродуманность языка - нужно перед каждым вызовом метода писать `$this->`, что очень визуально засоряет код.
В тестах реально много копипаста, без которого будет хуже.
>И именно поэтому нужно не копипастить, а выделять похожие участки кода в отдельные функции/классы.
"Заменить 20 строк копипасты 40 строками разного кода".
А еще на отдельные функции/классы тоже нужно написать тест.
Я написал себе хелпер-метод, который принимает vararg и радуюсь:
assertTru(a,b,c,d!=null,e,f,g==h);
Это пример, доработки, казалось бы известного, широкоиспользуемого фреймворка.
Но есть случаи где так просто копипасту не обойдешь
Есть проблема в таком подходе - на первый взгляд сложно понять, что же именно сломалось. Хорошо, если assertTru возвращает номер упавшего условия, но иногда он может просто не успеть этого сделать: assertTru(x != null, x.getAttr() == 5); легко может грохнуться с NPE.
Мне нравится подход property-based testing, реализованный, например, в QuickCheck. Но его, к сожалению, не всегда приемлимо применять.
Само собой.
>x.getAttr() == 5
Ну всегда можно завести int.
assertTru(()=>x != null, ()=>x.getAttr() == 5);
1. Соответствие распределения значений желаемому (обычно равномерное) - на достаточно большой выборке оно должно стремиться к идеальному
2. Независимость генерируемых значений друг от друга
3. Независимость от внешних факторов (кроме входного значения для ГПСЧ)
и т.п.
Общее правило: для вероятностных функций пишутся вероятностные тесты.
Кстати, linq это прикольно. Такой как-бы декларативный язык для выбора всякого говна из енумераблов, но при этом статически типизированный
Только беркли это кивалуе а не реляционка
https://www.sqlite.org/datatype3.html
SQLite does not have a storage class set aside for storing dates and/or times. Instead, the built-in Date And Time Functions of SQLite are capable of storing dates and times as TEXT, REAL, or INTEGER values:
• TEXT as ISO8601 strings ("YYYY-MM-DD HH:MM:SS.SSS").
• REAL as Julian day numbers, the number of days since noon in Greenwich on November 24, 4714 B.C. according to the proleptic Gregorian calendar.
• INTEGER as Unix Time, the number of seconds since 1970-01-01 00:00:00 UTC.
полез проверить один свой проектик, а там вот это вот всё
>Какой большой
Гост, что они с тобой сделали?
правда, не знаю, зачем завидовать такой длине
непрактично
Too long for gcc.
Нет, "MySQL" таким родился
Так и развивается
Бедного Fike заперли, и чтобы ему выбраться, пришлось освоить какой-то ключ…. (( owo
Иксы поддерживали компост когда еще даже kbd не было, а был один сраный xmodmap (да пребудет он на хую вечно!)
Странно, что ты только открыл
ничего, что женщин лапали сотрудники мужского пола?
нормально, что руководители приставали к женщинам?
а может нормально, то что одна сотрудница покончила с собой после мероприятий компании, где подверглась "харасменту"?