Примитивные модульные тесты
Это стоящий, чтобы записи модульные тесты на такой простой код:
public class TableController {
private TableView view;
public TableController(TableView view) {
this.view = view;
}
public void onShowTable() {
view.showTable();
}
}
У меня есть много такого очень простого кода в моих проектах, который подключает контроллеры, представления, услуги, удаленные услуги, и т.д. Модульные тесты просто повторяют все и обычно больше, чем сам код:
public class TableControllerTest {
@Test
public void showTable() {
TableView view = createMock(TableView.class);
view.showTable();
replayAll();
TableController controller = new TableController(view);
controller.onShowTable();
verifyAll();
}
}
Такие тесты действительно необходимы?
Спасибо!
7 ответов
Нет. Тебе не нужно все проверять. С другой стороны, можно попробовать перевернуть процесс и написать сначала тесты, а потом код. Во многих случаях вы обнаружите, что если вы сначала пишете тест, то в конечном итоге вы пишете другой код, который, как вы думали, вы будете писать с точки зрения того, каким должен быть результат при написании теста, а не с точки зрения того, какой код я должен писать. При таком способе написания тестов вы обнаружите, что тесты имеют гораздо большую ценность, чем просто выполнение кода с ними. Как только вы освоитесь, вы также почувствуете, когда вам нужен тест, а когда нет - автоматические аксессуары свойств, например, не нуждаются в юнит-тестировании IMO.
Если вы уже делаете тесты первыми, то я не уверен, что понимаю вопрос, так как ваши тесты не могут повторить то, что еще не было написано. Вы использовали свои тесты, чтобы определить, что должны делать эти методы. Это очень полезное занятие, а также защитное на случай, если другие тесты вызовут нарушение. Гораздо лучше найти это в юнит-тесте, чем в живом приложении.
Они нужны для того, чтобы при смене метода можно было убедиться, что он все еще работает. А когда это происходит через 2 года, уже поздно пытаться вспомнить, как работал метод для написания юнит-теста - это нужно сделать СЕЙЧАС.
Они нужны меньше, когда сравниваешь их с тестами на более сложных методах/логике, но все же нужны.
.Разные люди будут иметь разные мнения. Вам определенно нужно проверить все, что может пойти не так. Что это значит для вас, зависит от вас. Чрезмерное тестирование может замедлить производительность так же, как слишком малое тестирование может пропустить проблемы. Вам нужно определить, что работает для вас.
Тесты всегда хороши, особенно если вы ожидаете, что ваш код будет расти с течением времени. Полезно иметь возможность проверить, работает ли старый функционал после рефакторинга или внесения серьезных изменений в вашу базу кода.
В вашем конкретном случае, однако, я думаю, что функциональность этих битов кода слишком мала, чтобы извлечь выгоду из тестов и тестов, в которых более полезными были бы showTable и т.д.
код в моих проектах, который соединяет контроллеры, виды, сервисы, удаленные сервисы и т.д.
Для такого рода вещей юнит-тесты, вероятно, не полезны - но интеграционные тесты - это тесты, которые проверяют функциональность приложения в целом (возможно, на основе сценария использования) с минимальным насмешкой. Они занимают больше времени и не могут пройти через все краевые кейсы, но они очень полезны для выявления проблем в способе взаимодействия компонентов - и в подобном клеевом коде
.Я бы не стал тестировать простые методы делегирования.
Есть приятная поговорка (хотя я не могу вспомнить, от кого она исходила): "Никогда не проверяйте вещи, которые слишком просты, чтобы сломать..."
.Тесты для таких модулей на самом деле не нужны. Однако, тесты для таких модулей написать несложно. Так что писать тесты действительно нет ничего страшного. Также следует помнить, что простые модули такого типа имеют тенденцию расти со временем. Если у вас нет теста для модуля, то при добавлении нового бита логики в модуль, вы можете решить, что дельта между старым модулем и новой логикой слишком проста для тестирования. Бит за битом модуль растет, не будучи протестированным.
Так что, в конце концов, я напишу тесты даже для простых модулей, так как они просты в написании, и они выступают в роли держателей, когда модули становятся более сложными.