Как сместить Вашу парадигму к разработке через тестирование
Я предлагаю вам создать новый класс, например, где хранить номер и имя:
class NumberName {
Integer number;
String name;
// constructor, setter, getter
}
Затем при чтении из файла вы помещаете их в список:
[111 ]Тогда сортировка становится легкой:
list.sort(Comparator.comparingInt(NumberName::getNumber)); // by number
list.sort(Comparator.comparing(NumberName::getName)); // by name
list.sort(Comparator.comparing(NumberName::getNumber).thenComparing(NumberName::getName)); // by number then by name
6 ответов
Лучший способ взять TDD состоит в том, чтобы идти вперед и сделать это. Это - единственный путь до сих пор, который я имею, умеют получить коллег "тест, зараженный" - по крайней мере прямо сейчас у Вас есть хорошая оценка преимуществ заранее.
С более практической точки зрения, хотя, я думаю, Вы уже выделили одну из ключевых идей - это - изменение в планировании требований для того, чтобы создать приложение. Безотносительно методологии, которую Вы в настоящее время используете, если Вы видите слово как "требование", можно мысленно думать "тестовый сценарий" и по крайней мере иметь намерение записи тестового сценария сначала. Но точно так же, как другие ответы предлагают, TDD не является бескомпромиссным решением. Любой тест, который Вы пишете, каждый раз, когда Вы пишете это, прежде или после, полезен. Аналогично, не думайте, что можно когда-либо добираться до состояния, где Вы пишете все тесты заранее - это - цикл.
Моим фаворитом является псевдокод iat конец этого объекта в FAQ JUnit. Настроение тестового сценария является бесконечным циклом. Вскочите где угодно, любой тест, который Вы пишете, поможет, и Вы не будете сожалеть о нем.
Можно все еще протестировать в последний раз. Это хорошо. Мы простим Вам.
Изучите, как инструменты модульного теста работают на Вашем текущем языке.
Начните писать модульные тесты на то, что Вы продолжаете работать теперь.
В конечном счете можно переместиться в code-a-little-test-a-little. Затем test-a-little-code-a-little.
Чистая разработка через тестирование является идеалом. Практично, большинство людей test-a-little-code-a-little. Больше как регулирование теста или ведомый тестом, а не делавший пробную поездку.
Запустите теперь. Протестируйте что-либо, что Вы имеете под рукой.
Необходимо практиковать.
Можно запустить с теста, сначала программируя. Разработайте код, как Вы обычно делаете, возможно, не в глубоких деталях, и начинаете реализовывать его тест сначала: запустите с класса, который не имеет никаких зависимостей, посмотрите, как он может быть протестирован, записать список тестов, о которых можно думать. Начните писать самый простой тест. Затем напишите как раз достаточно кода, чтобы заставить его передать. Пересеките тест в своем списке и запишите это, напишите код.
Когда Вы имеете идею для нового теста или задаете себе вопрос о том, как код ведет себя при определенном условии, добавьте новый тест к своему списку.
Я рекомендовал бы Вам тест чтения Управляемая Разработка; это - очень хорошее введение в TDD и также содержит много ссылочных материалов (названный шаблонами).
Относительно оценок одна вещь иметь в виду состоит в том, что хотя при написании кода и тестов одновременно немного длиннее, чем просто написание кода, Вы заканчиваете кодом, который работает.
Еще некоторый совет, после того как Вы начнете:
Добавьте новый провальный тест прежде для решения любой проблемы в коде.
Стремитесь никогда не записать любую строку кода, не имея провального теста - это - конечная цель.
В дополнение к тому, что. Lott говорит, посмотрите на то, как Витрина MVC структурирована.
Как они обрабатывают тестирование с данными, которые прибывают из базы данных? Как они обрабатывают тестирование, которым Контроллер управляет правильно? Как они обрабатывают, когда класс имеет другие зависимости?
При взгляде на то, как TDD требует, Вы для структурирования программы действительно поможете, после того как Вы имеете мимо основ (???) Единица
Я не вижу, почему Вы не могли только начать использовать TDD. Вы не должны создавать весь свой код с помощью практики - просто используют его для одного класса день или один час день, для начинающих. Когда Вы становитесь более удобными, расширяете приложение практики к большему количеству Вашего кода.
Также помните, что TDD является большим количеством стратегии проектирования, чем стратегия тестирования. Будьте открыты для того, что тесты говорят Вам о производственном коде. Всегда осуществляйте рефакторинг беспощадно - особенно вначале, допускайте ошибку со стороны слишком большого рефакторинга, если в сомнении.
Если можно найти некоторых аналогично мыслящих людей, рассмотрите проведение додзе кодирования; это - большой, интересный способ освоить новый навык программирования: http://codingdojo.org/
Даже если Вы - написание кода сначала, спросите себя, поскольку Вы пишете это, "действительно ли это является тестируемым?" Если это не, затем Вы могли бы хотеть заново продумать свой дизайн для конкретной части кода, который Вы пишете. Если это, то идите вперед и закончите его и запишите некоторые тесты позже. Я нахожусь в коде немного, тестовое немного мышление сам прямо сейчас.