Лучший способ добавить тесты к существующему проекту направляющих?
Я думаю, что вы должны пойти с обрезкой '/' в конце
public static string GetUserNameInstagramUrl(string url)
{
Uri uri = new Uri(url);
return uri.Segments.Last().TrimEnd('/');
}
5 ответов
Этот вопрос недавно подошел в списке рассылки RSpec, и совет, который мы обычно давали, был:
- не потрудились пытаться модифицировать спецификации к существующему, работе, код, если Вы не собираетесь изменить его - это является исчерпывающим и, если код не должен быть изменен, довольно бессмысленный.
- Начинают писать спецификации для любых изменений, которые Вы вносите с этого времени. Исправления ошибок являются особенно хорошей возможностью для этого.
- Попытка обучить себя в дисциплину, что перед касанием кода, в первую очередь, запишите провальный пример (=spec) для вытеснения изменения.
можно найти, что дизайн кода, который не был вытеснен примерами кода или модульными тестами, делает это неловким к тестам записи или спецификациям для. Это, возможно, на что ссылался Ваш друг. Необходимо будет почти наверняка изучить несколько ключевых методов рефакторинга для разбивания зависимостей так, чтобы можно было осуществить каждый класс в изоляции от спецификаций. Превосходная книга Michael Feathers, Работа Эффективно С Унаследованным кодом имеет некоторый большой материал, чтобы помочь Вам освоить этот тонкий навык.
я также поощрил бы Вас использовать встроенную задачу граблей spec:rcov генерировать статистику покрытия кода. Чрезвычайно полезно наблюдать, что эти числа повышаются, поскольку Вы начинаете получать свою кодовую базу под тестом.
Принятый ответ является хорошим советом - хотя не практичный в некоторых случаях. Я недавно столкнулся с этой проблемой на нескольких моих приложениях, потому что мне БЫЛИ НУЖНЫ тесты для существующего кода. Просто не было никакого другого пути вокруг этого.
я начался, делая все модульные тесты, затем перешедшие на functionals.
Привыкают писать проваливающие тесты на любой новый код, или каждый раз, когда Вы собираетесь изменить часть системы. Я нашел, что это помогло мне получить больше знания тестирования, когда я иду.
Использование rcov для измерения прогресса.
Удачи!
Возможно, запустите с моделей? Они должны быть тестируемыми в изоляции, которая должна сделать их зависающими самым низким образом фруктами.
Затем выбирают модель и начинают писать тесты, которые говорят, что она делает. Как Вы продвигаетесь, думайте о других способах протестировать код - там пограничные случаи, в которых, возможно, Вы не уверены? Запишите тесты и посмотрите, как модель ведет себя. Поскольку Вы разрабатываете тесты, можно видеть области в коде, которые не являются столь же чистыми и дедуплицированы (DRY), как они могли бы быть. Теперь у Вас есть тесты, можно осуществить рефакторинг код, так как Вы знаете, что не влияете на поведение. Попытайтесь не начать улучшать дизайн, пока Вы не имеете в распоряжении тесты - тот путь находится безумие.
, После того как Вам придавили модели, переместиться вверх.
Это - один путь. Альтернативы могли бы запускаться с представлений или контроллеров, но можно найти, что это легче запуститься со сквозной транзакции тестирует andwork путь в мелкие и мелкие кусочки, как Вы продвигаетесь.
Запись тестов для существующего кода может показать ошибки в Вашем коде. Эти тесты вынудят Вас посмотреть на существующий код, таким образом, Вы будете видеть то, что тестирует Вас, должен записать, чтобы заставить его передавать, и можно видеть некоторый код, который мог возможно быть написан лучше или теперь бесполезен.
Другая подсказка должна записать тест при обнаружении с ошибкой, таким образом, она никогда не должна повторяться, это называют тестированием regressional.
Модифицирование спецификаций не является неизбежно плохой идеей. Вы идете от рабочего кода до рабочего кода с известными свойствами, который позволяет Вам понимать, повреждает ли какое-либо будущее изменение что-нибудь. В данный момент, если необходимо внести изменение, как можно знать то, на что оно будет влиять?
, Что имеют в виду люди, когда они говорят, что трудно добавить, тесты/спецификации к коду exisitng - то, что код, который трудно протестировать, часто высоко связывается, который мешает писать, что низкий уровень изолировал тесты.
Одна идея состояла бы в том, чтобы запуститься с тестов полного стека с помощью чего-то как бегун истории RSpec. Можно затем работать от 'снаружи в' изоляции, что Вы можете в изолированных тестах низкого уровня и постепенно распутывать более твердый код поразрядно.