Дэвид Хайнмайер Ханссон (DHH) недавно заявил, что разработка через тестирование (TDD) мертва . Многие ответили, включая ThoughtWorkers, заявив, что это не так. Я думаю, что есть ссылка на рефакторинг или, точнее, возможность рефакторинга для рассматриваемой технологии.
Рельсы это 4GL
Рамки DHH Rails очень продвинуты. Однажды я слышал, что это больше похоже на 4GL, а сам Ruby — 3GL. Конечно, вам нужно быть достаточно взрослым, чтобы знать, что означает категоризация, поскольку индустрия подталкивает к созданию подлинных 4GL, которые позиционируются как панацея. В 90-х я имею в виду, когда «Приготовь чашку чая» был способ быстро привести пример того, что будут делать 4GL (когда они прибудут). В любом случае, 4GL пришли и ушли к концу 90-х, слава богу. Заявление Rails == 4GL в 2005 году, однако, вызвало отклик.
Признание (отступление)
Для меня Rails был пропущенной лодкой. Дэн Норт познакомил меня с DHH в JAOO в 2003 году. Или DHH нашел меня. Он продемонстрировал раннюю версию Rails. Я был парнем из PicoContainer / Java, и, возможно, я мог бы помочь ему тогда. Конечно, я на самом деле не получил полноценного предложения и вежливо предположил, что оно не будет масштабироваться на предприятии (или какой-то другой лжи), и пошел дальше. Я сделал пометку о том, чтобы заняться DHH в качестве найма ThoughtWorks после конференции, но так и не последовал. Не менее важно то, что я не следил за интуитивным чувством, что мне нужно больше копаться в том, что этот парень показал мне. Неважно, Оби Фернандес поймал мой сброшенный мяч, и к концу 2004 года ThoughtWorks изменила свою базу разработчиков, чтобы стать пионером в разработке Rails.
Ссылка на рефакторинг (из названия статьи)
Возможно, приложения на Rails слишком сложны с точки зрения конструкций кодирования, чтобы их можно было легко и дешево протестировать. По крайней мере, по сравнению с Java. Возможно, фреймворки сложнее для TDD по сравнению с библиотеками. Помните, что библиотека, как правило, контролируется вашим кодом и не имеет побочных эффектов вызова (без потоков, повторного входа и т. Д.). Фреймворк обычно контролирует ваш код. Действительно, фреймворк часто создает экземпляры классов вашего приложения и выбирает свои собственные моменты для вызова методов. Там много магии, и «швы», которые мы ищем для плавных испытаний, часто отсутствуют. Известно, что некоторые фреймворки, такие как ранние версии .Net ASP.Net, сложно тестировать, не говоря уже о тест-драйве. Вообще говоря, никто не хотел бы, чтобы больше кода было просто тестируемым, и Rails в 2004 году, безусловно, был намного меньше кода для того же.
Рефакторинг в таких инструментах, как Intellij для Java, похож на то, чтобы дать Мона-Лизе правильную улыбку пальцами, спустя сотни лет после последнего мазка, и идеально. Не только это, но и отмена истории Интеллиджа тоже прекрасна. Не нравится эта улыбка? Нажмите Ctrl-Z.
Не могу рефакторинг означает, что не будет рефакторинг
Я утверждаю, что TDD без затрат на создание или обслуживание требует поддержки рефакторинга в ядре. Любой, кто использует IDE (или редактор), у которого нет поддержки рефакторинга для данного языка, будет иметь TDD второго класса.
Любой, кто влюблен в их IDE-редактор, у которого нет поддержки рефакторинга, будет иметь отношение Басиана к «Я думаю, что TDD переоценен», потому что это соответствует их выбору инструмента. Короче говоря, если вы любите IDE, которая не может выполнять рефакторинг, ваш уклон подтверждения означает, что вы, вероятно, думаете, что такие вещи, как TDD, облегчают рефакторинг, но они того не стоят.
… Ваш уклон подтверждения означает, что вы, вероятно, думаете, что такие вещи как рефакторинг, такие как TDD, не стоят того
Полное раскрытие: я не знаю, что использует IDE DHH.
JetBrains, AngularJS и рефакторинг
Конечно, это мягкий ответ из центральной позиции этой статьи «не может быть рефакторинг не будет рефакторингом», но это связано.
JetBrains выпустила RubyMine 1.0 в апреле 2009 года, но публичный предварительный просмотр был доступен с ноября 2008 года . Именно тогда рефакторинг стал случайной возможностью для приложений Rails — до определенного момента, и только если вы, конечно, использовали RubyMine (вместо вашей любимой IDE / редактора). Насколько далеко зашла сегодня возможность рефакторинга RubyMine для приложений Rails, это совсем другое.
Угловое в 2012/13 является промышленность голубчик , что Rails была в 2006/7. Не только на мой взгляд. Это еще одно предложение «меньше кода», и оно заслуживает покровительства.
В 2009 году я посмеивался над описанием (Googler) Миско его нового сайд-проекта AngularJS. Завтрак перед хакатоном GoogleWave с Олой Бини, на следующий день после объявления Wave, был неподходящим моментом для просмотра кода, поэтому мы пошли дальше, но Миско был немного задет. Я знал, что я не был почтителен, и у меня была соответствующая боль вины / стыда там и тогда. Это внутреннее чувство вернулось — я должен взглянуть еще раз. Все еще чувствуя боль от того, что был ThoughtWorker, который сбросил мяч с Rails, я думал, что не совершу одну и ту же ошибку дважды — я копал глубже несколько дней спустя — и «удар гения» был моим постоянным чувством. Вскоре после этого я сделал свою первую запись в блоге Angular., Я думаю, что Миско забыл, что я посмеивался над его умным ребенком в качестве первой реакции, и это одна из отличительных черт его личности, которую я видел в некоторых других супер-достижениях.
В любом случае, JetBrain внедрил возможности AngularJS в свой набор продуктов. Рефакторинг специфических вещей Angular теперь реальность — ура!
Встраивание функции JS в атрибут Angular
Если вы выберете ссылку на функцию контроллера на странице HTML в WebStorm, вы увидите меню рефакторинга (пример Angular от todomvc.com):
Выбор inline даст такой код:
По какой-то причине Ctrl-Z еще не полностью подключен (локальная история), но контроль версий всегда позволяет своевременно вернуться, как и должно быть.
Я весьма доволен этим как ранним достижением рефакторинга для WebStorm (и я полагаю, что все другие IDE JetBrains по очереди), но что я действительно хочу, это «директива extract / inline», «extract / inline service» и другие Angular идиомы. Я не сомневаюсь, что JetBrains попадет туда вовремя.
Где разместить JavaScript в Angular проектах?
Как мы видели с …
<button class="destroy" ng-click="todos.splice(todos.indexOf(todo), 1);"></button>
… У нас фактически есть JavaScript в атрибутах Angular. В этом случае это слишком много, но, на мой взгляд, простые выражения вполне подходят. Где находится точка отсечения для того, что вы должны / не должны делать в выражении в атрибуте HTML? Это важно, потому что это код, который не может быть протестирован в стиле xUnit. Если он не может быть протестирован, он не может быть частью сборки TDD. Вы всегда можете протестировать его на этапе Selenium-WebDriver, ориентированном на компоненты, но это не тесты в стиле xUnit. Тесты Selenium на узком уровне компонентов не будут иметь время выполнения менее 1 мс, как обычно делают тесты xUnit, даже если вы можете утверждать, что у вас более полный охват.
Я не пропускаю тестирование JavaScript Я не пишу
Хотя я не пропускаю тестирование JavaScript, я не пишу, этот фрагмент должен иметь тесты. Со временем мы получим программное обеспечение помощника по тестированию, которое извлечет все фрагменты углового выражения в место, где могут быть тесты:
$tests.destroy_button.ngClick = function (todos, todo) {
todos.splice(todos.indexOf(todo), 1);
};
// or something similar that would parse w/o error.
Если бы AngularJS (и другие фреймворки, имеющие магию) могли генерировать тестируемые интерпретации кода магии (и прекрасно управлять ими во время рефакторингов), то мы могли бы увидеть TDD с полной скоростью для этих фреймворков.