Какие модульные тесты должны быть записаны для простого ПОСТЕПЕННО объекты области?
Если вы хотите добавить метаданные, вам не нужно искать Order_ID, из кода ниже вы можете легко это сделать.
function _woocommerce_add_order_item_meta_new_ver($item,$cart_key,$values) {
//HERE product_meta is just a random key I have used here, you have to use your key here
if (isset ( $values ['product_meta'] )) {
foreach ( $values ['product_meta'] as $key => $val ) {
$order_val = stripslashes( $val );
if($val) {
if($key == 'your_cart_item_key') {
$item->add_meta_data('Your Key',$order_val);
}
}
}
}
}
//This will add "Your Key" in your order_item_meta, just make sure you have used the same key "your_cart_item_key" in your cart_item_meta key too.
5 ответов
Обычно объект значения как этот не должен иметь своих собственных тестов. Вы получите покрытие от классов, которые используют его, чтобы на самом деле сделать что-то.
Модульные тесты разработаны для тестирования поведения. Никакое поведение? Никакая потребность в тесте.
На самом деле я думаю, начали ли Вы писать тесты для этого кода перед записью класса реализация будет отличаться. Например, Вы, вероятно, закончили бы тем, что писали конструктору, который инициализирует Ваш набор так, чтобы можно было сослаться на него, не имея необходимость проверять на пустой указатель каждый раз. Я думаю, что это - вероятно, хорошая практика для записи тестов, даже если Вы не думаете, что Вам нужны они. Часто в записи тестов Вы находите, что существует много предположений, что Вы сделали, который не был бы обращен с Вашей первой попыткой кода.
Например, ContainerId мог когда-либо быть меньше, чем нуль? Это была бы ошибка попытаться установить его на отрицательную величину? Набор должен быть инициализирован конструктором, т.е. должны классы, которые используют этот контейнерный класс, должны проверить на пустой указатель прежде, чем получить доступ, или Вы хотите гарантировать, что набор никогда не будет пустым, хотя это могло бы быть пусто?
Тем не менее я обычно применяю некоторую исправность к процессу. Например, если я знаю, что конструктор внутренне ограничен по объему, и объекты только создаются классом Фабрики. Я протестирую методы фабрики гарантировать, чтобы они всегда произвели легальные объекты, но не обязательно протестировали сам контейнерный класс.
Я предполагаю, что нижняя строка, для меня так или иначе, состоит в том, чтобы предположить, что классы нуждаются в тестах, пытаются записать им и только опустить их, когда я не могу думать о значимом тесте для записи.
это - просто моя привычка, и я ни в коем случае не end-all-be-all к этому, но я не пишу тесты, пока у меня нет конструктора, который на самом деле делает что-то (т.е. значения по умолчанию набора).
Необходимо протестировать собственный код, не язык. Вам гарантируют каждый раз, когда Вы новый Контейнер () Вы собираетесь получить новый Контейнер. И, если Вы действительно портите тот шаг, компилятор собирается поймать его.
Мне нравится думать о модульном тесте как о "вызове" единицы намерения.
Единственные намерения, выраженные Вашим кодом, являются методами считывания и методами set; будучи частью языка, мы предполагаем, что они работают.
Никакого другого намерения не выражают, и таким образом никакие тесты не требуются.
Я предложил бы удалить метод set из Contents свойство, как бы то ни было. Свойства набора должны быть только для чтения.
Я утверждал бы, что это даже не объект - и объект определяется его поведением, и этот класс не имеет никого. Это - чистый контейнер данных. Нормально иметь их, также - и они обычно не нуждаются ни в каких тестах - но Остерегаются этого, Вы не заканчиваете с Анемичной Моделью предметной области. Используя Разработку через тестирование "вынудил" бы Вас сначала думать о поведении своих классов и могло бы быть хорошее осуществление.