TDD и сжатие JPEG
Это потому, что вы выбираете пустой контейнер для Pjax. Давайте проверим вашу HTML-структуру:
<body>
<ul>
<li><a href="/" class="current">MAIN PAGE</a></li>
<li><a href="/Home/About">About</a></li>
</ul>
<div id="main">@RenderBody()</div>
</body>
и вы инициализируете pjax, как показано ниже:
$('ul a').pjax('#main')
Обратите внимание, что #main не является потомком ul.
Чтобы исправить свой код, просто попробуйте:
$(document).pjax('#main')
Или, если вы хотите настроить селекторы, попробуйте следующие примеры:
$(document).pjax('a', '#main')
$(document).pjax('ul a', '#main')
3 ответа
Вопрос Joel был чем-то вроде этого. Предположим, что Вы хотели установить немного где-нибудь, которое заставило изображение с невысокой четкостью быть отображенным, а не изображение высокого разрешения. Как Вы использовали бы TDD, чтобы заставить это работать? Вы записали бы тест, который очистил экран, чтобы показать, что изображение было в низком res?
, Конечно, нет. Вы уже знаете, что библиотека JPEG работает. Вы уже знаете, что при вызове его с правильными аргументами, это отобразится в низком разрешении. То, что необходимо протестировать, - то, что бит, который Вы устанавливаете, переводится в соответствующие вызовы в библиотеку JPEG. Таким образом, Вы дразните библиотеку JPEG с очень простым модулем, которым управляет Ваш тест. Тогда Вы устанавливаете бит и запрашиваете дисплей. Библиотека Mocked JPEG будет помнить, как это назвали, и затем тест может проверить, чтобы быть уверенным, что это назвали правильно.
хорошо, поэтому как Вы протестировали бы внутренности библиотеки JPEG? Я не знаю много о рендеринге JPEG, но я предполагаю, что это о сжатии, распаковке и битовых массивах. Сжатие и распаковка являются просто алгоритмами. Алгоритмы имеют предсказуемые выводы от данных исходных данных. Таким образом, Вы настраиваете серию очень простых исходных данных и удостоверяетесь, что получаете предсказуемые выводы. Вы настраиваете исходные данные так, чтобы внутренности алгоритмов JPEG были покрыты. Та же логика содержит для битовых массивов. Вы не должны представлять их на экране. Простые небольшие битовые массивы могут быть представлены в буферах памяти, которые могут исследовать тесты. Простым я имею в виду ПРОСТОЙ. 3X3, 5X5, 8X8. Простой. Снова, Вы структурируете свои входные данные для покрытия объема кода.
Ни одно из этого не аэрокосмические исследования. Ни один, если это прекрасно. Но комплект 50 тестов, который демонстрирует, что 90% Вашей логики корректны, может иметь огромное значение, когда Вы хотите внести изменения.
можно ли когда-либо полностью устранять ручное тестирование? Конечно, нет. Но Вы можете значительно смягчать его. Можно уменьшить ручное тестирование до нескольких очень стратегических тестов, а не тысяч крайне утомительных планов тестирования.
Если Вы думаете, что проверки материального положения TDD происходят перед любым кодом или любым дизайном, это в основном невозможно. Для сложных алгоритмов Вам нужны некоторые результаты. И в случае сжатия, к результатам трудно привести вручную. Не невозможный, но трудно.
Далее, сжатие требует очень высокоэффективного алгоритма. Просто проходить тест не довольно достаточно хорошо. Много низкоэффективных алгоритмов могут пройти основной тест "правильности".
Для перемещения вне правильности Вам нужно доказательство, что Ваш алгоритм оптимален. Это может только быть разработано вне мировоззрения тестирования. Вам нужен анализ сложности с помощью [1 116] O ( что-то ), который не является результатами теста; и при этом это не может быть четко определено как результаты теста.
, Если с другой стороны, Вы думаете, "тестируемость" прибывает перед большей частью кода тогда это легко.
-
Дизайн Ваш алгоритм. Запишите доказательство, что это оптимально.
-
Пишут некоторый код, который представляет критические части Вашего алгоритма как тестируемые модули.
-
В некоторых случаях, напишите код для создания результатов испытаний для полного алгоритма. Это может быть субоптимальным, кодом "в лоб", который производит правильный ответ через действительно очевидные, но медленные алгоритмы.
-
Собирают unittest, чтобы показать, что Ваша реализация производит ожидаемые результаты испытаний.
-
Собирают технический документ, чтобы показать, что это также оптимально.
Это не тест сначала. Но на этом делают пробную поездку.
Разработка через тестирование не только программирует, существует много других вещей, можно сделать тест использования сначала, примеры с принятием tdd, и т.д.
Думают сначала, как Вы хотите, чтобы это вело себя, это - вещь. Для алгоритма пример мог быть чем-то как:
- "Это должно завершить 5 вызовов через 10 секунд"
- , "Это должно уменьшить до 10% размер изображения"
- Другие.
я полагаю, что это - только образ жизни для размышления ясно, что Вы хотите выполнить: D