test-driven development
TDD давно уже не новость, и в веб-картах нокии мы этот подход активно применяем. Однако я никогда не был приверженцем такого подхода, и мне даже не хотелось его попробовать. До тех пор, пока пару дней назад я не понял очень простую вещь, которую никому из проповедников TDD не удавалось донести до меня раньше, уж не знаю, почему
когда я пишу код, я довольно часто проверяю его работоспособность, обычно примитивными методами типа вывода в консоль или alert. Увидев ожидаемый результат, продолжаю писать код дальше. Однако часто, чтобы добиться появления проверочной строчки в консоли, нужно совершить много действий: покликать туда-сюда, что-то набрать на клавиатуре, и всё такое. Повторять эти однообразные действия раз за разом долго и скучно, поэтому разумно их автоматизировать. Тогда вместо обновления страницы в браузере или перезапуска программы в консоли можно запустить тест. А потом эту автоматическую проверку можно сохранить и на будущее
я помню, как в описании TDD я читал нечто вроде: «сначала мы создаём набор тестов, а потом пишем код, чтобы он проходил эти тесты». В этом описании слишком много планирования, на мой вкус. Начиная программировать, я часто слабо представляю даже структуру кода, не говоря уже об именах объектов и методов. Как в такой ситуации можно писать тест? А вот когда несколько строчек уже есть, и понятно, как что называется, тогда вместо интерактивной проверки состояния программы можно и тест написать. Один тест, который проверит то, что важно прямо сейчас
вот такой подход мне интересно попробовать, от такого можно ожидать жизнеспособности. Нужно посмотреть, конечно, как оно переживёт постоянные рекфакторинги и работу с GUI, но теперь мне хотя бы стало интересно
если же именно это и является правильным способом применять TDD, то окажется, что очень многие тесты в нокии написаны совершенно бездумно. Например, если функция вызывается с одним параметром-объектом, который создан литералом прямо внутри вызова, типа do({…}), то зачем в тесте проверять, что внутрь придёт именно такой объект? Зачем проверять, что субпроцедуры вызваны, если функция линейная? Неудивительно, что такие тесты не вызывают желания заниматься TDD