Я всегда скептически относился к переписыванию рабочего кода - портирование кода не является исключением. Однако с появлением TDD и автоматизированного тестирования гораздо разумнее переписать и реорганизовать код.
Кто-нибудь знает, есть ли инструмент TDD, который можно использовать для портирования старого кода? В идеале вы могли бы сделать следующее:
- Запишите независимые от языка модульные тесты для старого кода, который проходит (или не проходит, если вы обнаружите ошибки!).
- Запустите модульные тесты на другой базе кода, которые не пройдут.
- Напишите код на вашем новом языке, который проходит тесты, не глядя на старый код.
Альтернативой может быть разделение шага 1 на «Записать модульные тесты на языке 1» и «Переносить модульные тесты на язык 2», что значительно увеличивает требуемые усилия и трудно обосновать, если старая кодовая база перестанет поддерживаться после порт (то есть вы не получаете преимуществ от непрерывной интеграции на этой базе кода).
РЕДАКТИРОВАТЬ: Стоит отметить этот вопрос на StackOverflow.
unit-testing
language-agnostic
porting
Bringer128
источник
источник
expectдля реализации ваших тестов.expect. Если у вас есть устаревшая система в стиле Unix, которая взаимодействует с каналами с использованием stdin и stdout, тогда этот инструмент можно использовать наверняка. На самом деле, было бы довольно легко протестировать и на любом языке сценариев.legacy language xкfancy new language y. Я не пытался что-либо подразумевать в Unix!Ответы:
Я не думаю, что можно написать модульные тесты на другом языке.
Однако вы можете написать тесты интеграции / принятия / пользовательского интерфейса / whaterver_you_name_it, которые будут очень высокого уровня и не будут привязаны к языку, на котором написано ваше программное обеспечение.
Если ваше приложение является веб-сервисом, вы можете протестировать его на любом языке, который вам нужен, при условии, что оно поддерживает ваш протокол. Если ваше приложение запускается в браузере, вы можете использовать селен (это первое, что пришло мне в голову, но есть и другие. И т. Д. Могут быть случаи, когда это не сработает, я думаю (может быть, аппаратное обеспечение), все зависит на тип приложения, над которым вы работаете.
Конечно, у вас не будет такого покрытия, как у вас на юнит-тестах (если вы не тратите много времени), но, по крайней мере, у вас будет тестовая привязь.
источник
Я думаю, что ближе всего к вашей идее являются рамки модульного тестирования в экосистемах на основе виртуальных машин, таких как Java VM. По крайней мере, Scala (и я считаю, что Groovy тоже - я не совсем уверен в Clojure) почти идеально совместим с Java. То есть код Scala можно тестировать с помощью JUnit, а код Java - с помощью ScalaTest. Таким образом, вы можете (постепенно или сразу) переписать код Java в Scala и продолжать использовать те же самые старые модульные тесты Java, чтобы проверить его правильность. (Или наоборот - хотя я не могу представить себе вескую причину для перехода с Scala обратно на Java.)
Вероятно, то же самое относится к языкам в .NET CLI, например, C #, F #, ASP.NET et al.
Вне VM / CLR, однако, это сложнее. Теоретически можно скомпилировать модульные тесты и / или тестируемый код на другом языке, таком как C (как это было и является обычным для новых языков, таких как ранний C ++ и т. Д.), Но я не слышал, чтобы кто-нибудь специально пытался это сделать с модульные тесты.
источник
Такой структуры не существует, потому что она должна быть написана на языке используемого кода.
Например, инфраструктура для тестирования кода на c ++ должна быть написана на c или c ++. Использование фреймворка, написанного на c ++, возможно, но он не собирается тестировать код ac, если он использует функции c ++.
источник
Методологии меняются, но в моем случае большая часть моих тестов TDD имеет тенденцию к «интегральному тесту», в отличие от «модульного теста». То есть большинство из них тестируют всю программу в почти реальных запросах, проверяя соответствующие ответы.
В некоторых случаях, когда я писал программы, управляемые сетью (в основном протоколы для конкретных приложений), у меня не было под рукой полной инфраструктуры тестирования, которая была бы удобной для работы, поэтому я проводил большую часть тестирования «по сети», в Короче говоря, я написал очень простой клиент на другом языке с общей и простой структурой тестов, и большинство тестов проверяли ответы сервера.
Тем не менее, даже в этих случаях я вводил несколько тестов в реальном приложении, чтобы протестировать некоторые не сетевые компоненты.
источник
Фреймворк для независимого от языка теста - это универсальная тестовая среда, подходящая для приемочного теста (точка зрения), и тестовые случаи в этой среде управляются QA, например, Robotframework
источник