How to become an author
Search
Write a publication
Pull to refresh

Comments 25

Если я пишу код на Go, мне не нужно писать тесты.

Правда? Или, может быть, все-таки "мне не нужно писать некоторые тексты"?

Total votes 5: ↑5 and ↓0+5

Так и есть. В оригинале:


If I am writing Go code, there is a small mountain of tests that I will never have to write.

Не "мне не нужно писать тесты", а "некоторые тесты мне никогда не придется писать".

Total votes 2: ↑2 and ↓0+2
Мне на секунду показалось, что компилятор Go имеет искусственный интеллект :)
Total votes 1: ↑1 and ↓0+1

Маленькое уточнение. Это предложение переводится как — Если я пишу код на Go, то из тестов, которые мне не придётся писать можно сложить небольшую гору.


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

Total votes 2: ↑2 and ↓0+2
Зачем писать юнит-тест на неправильное использование чего-либо? Можно придумать стремящееся к бесконечности число способов неправильного использования любого мало-мальски большого кода.
Нам необходимо проверить, что наш код работает корректно, а не что если мы напишем некорректный код — он будет работать корректно. Вот и стоит писать тесты на приложение. И негативные тесты только там, где реально может прийти что-либо неожидаемое. Должны упасть если неправильный ввод пользователя или недостаточно данных? Окей. Но проверять, что функция analyzeString() будет падать, если передать в нее массив, объект, число или яблоки — моветон. Все-равно свалятся более высокоуровневые тесты кода, который так странно использует эту функцию.
Total votes 5: ↑5 and ↓0+5
пс. Хотя да, статическая типизация — огромное преимущество. И не только из-за тестирования.
Total votes 2: ↑1 and ↓10
Зачем писать юнит-тест на неправильное использование чего-либо?

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

Total votes 2: ↑1 and ↓10

Не стремящееся к бесконечности, а ровно бесконечность. Но на то и существуют классы эквивалентности, чтобы сократить число подобных вариантов к минимуму.

Total votes 2: ↑0 and ↓2-2
UFO just landed and posted this here

Ну офигеть, а то мы не знали преимуществ статической типизации.
А ведь вместо написания статей, автор мог бы научится нормально писать юнит-тесты.

Total votes 12: ↑12 and ↓0+12

Вы слышали про такого человека, как Роберт Мартин? Он же дядя Боб. Вот он утверждает, что если к динамичекому коду добавить юнит тесты, то у статистически типизированного кода не будет преимуществ перед динамически типизированным кодом.

Total votes 2: ↑1 and ↓10

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

Total votes 2: ↑1 and ↓10

Роберт Мартин вот утверждает, что 100% это как раз реальные цифры. И что отсутствие стопроцентного покрытия гарантирует проблемы.

This comment wasn’t rated yet0
Роберт Мартин вот утверждает, что 100% это как раз реальные цифры
Цитату можно?
И что отсутствие стопроцентного покрытия гарантирует проблемы.
Каким образом?
This comment wasn’t rated yet0

Цитату можно. Вот она.


Am I suggesting 100% test coverage? No, I’m demanding it. Every single line of code that you write should be tested. Period.

Что касается того, каким образом отсутствие стопроцентного покрытия гарантирует проблемы — у Мартина вообще много про это. Книги Clean Code и Clean Coder этого касаются. Наверное можно вот эту статью почитать.

This comment wasn’t rated yet0
Цитату можно. Вот она.
Так он не говорит, что это реальные цифры. Он говорит что настаивает на их достижении. На практике мало кому это удается.
Что касается того, каким образом отсутствие стопроцентного покрытия гарантирует проблемы — у Мартина вообще много про это.
Не знаю что там у Мартина, но по законам формальной логики отсутствие проверки не может гарантировать наличие ошибки. А кроме того стопроцентное покрытие не гарантирует отсутствие проблем (а лишь отсекает их часть).
This comment wasn’t rated yet0
Дядюшка говорит о том, что нет других способов поставить задачу кроме тестов. Текстовое или устное описание ТЗ он не считает за требования. С его точки зрения нельзя говорить о не 100% покрытии кода тестами, ведь только код, написанный для этой задачи (определенной тестами) и является кодом ЭТОГО проекта. А остальной код он отношения не имеет к делу и чем он там покрыт не важно.
Собственно, тесты и определяют «работоспособность».
Тут фишка заключается в том, что если заказчик дает вам задания не в виде формальных спецификаций (это те, которые трактуются однозначно), то вы должны их написать сами или не писать код вовсе.
А код, написанный без таких требований это интуитивная попытка угадать их, не формализуя, а вернее формализуя где-то в подсознании. Отсюда и все последующие проблемы — «не угадал», «угадал, но немного не так». Обобщая, вы становитесь «частью заказчика».
Total votes 1: ↑1 and ↓0+1
у статистически типизированного кода не будет преимуществ перед динамически типизированным кодом.

Я вот не могу согласиться. Кроме тестирования это ещё локальная самопроверяющаяся документация и хорошая поддержка ИДЕ. Это кое-как можно сделать через всякие там JSDoc, но это не так удобно и не так хорошо поддерживается.
Total votes 1: ↑0 and ↓1-1

Я тут тоже с Мартином не согласен. Но сам факт существования подобной точки зрения однозначно говорит, что статьи о том, что статическая типизация полезна — нужны.

Total votes 2: ↑1 and ↓10
В динамических языках можно платить за проверки (написанием большего числа тестов), только если они нужны. Полно случаев, когда вполне можно обойтись без них, написав код без траты времени на продумывание типов
Total votes 2: ↑2 and ↓0+2
Все дело в повторном использовании и написании интерфейсов в связи с этим, во всех остальных случаях всегда можно вывести и проверить типы автоматически.
Total votes 1: ↑1 and ↓0+1
Для автора, видимо, смысл юнит-тестов заключается в том, чтобы проверить ту или иную функцию, да и вообще что код запустится. В то время как юнит-тестирование не означает исключительно тестирование функции на разных параметрах, это что-то пошире. Само слово unit-testing говорит, что это тестирование модуля и его поведения. Следовательно, тестировать разумно результат, а не сам процесс, ведь одного и того же результата можно достигнуть множеством путей. Считаю, что автор статьи забыл добавить три важных слова: «По моему мнению».
Да, под автором я понимаю именно автора, а не переводчика, которому спасибо)
This comment wasn’t rated yet0
Мне больше нравится тот замечательный бонус к компилируемым языкам программирования, который называется линкер. Представьте, что в ваш проект попадают те и только те участки кода, которые реально используются. Это же так здорово!
В случае же интерпретируемых языков всё не так радужно. Используете всего пару функций из jQuery? Ваш проект поправится на полный объём этой библиотеки. Используете всего 5% тех возможностей, которые предоставляет AngularJS? Ваш проект неминуемо вырастет сразу на полметра. И так может дойти до того, что простенькая страничка тянет за собой 10Мб зависимостей, из которых реально выполняется порядка 40Кб. Ну не бред ли?
This comment wasn’t rated yet0
И тут на сцену выходит webpack tree-shaking

P.S. Автору статьи надо бы узнать про TDD, а еще про моки.
Total votes 1: ↑1 and ↓0+1
Sign up to leave a comment.

Your account

Sections

Information

Services

Support
© 2006–2024, Habr