Иногда, обычно когда вы никогда не писали тест, написание юнит-теста кажется трудной и сложной задачей, но это не так, этому чувству есть некоторые объяснения и мы обсудим его в этой статье. Когда я решил узнать о модульных тестах, я зашел в документацию по тестам Google Android, много прочитал и понял, что это кажется проще, чем я думал, но когда я попробовал, тест просто не работает, что бы я ни пытался. Несколько недель спустя, изучив больше, я понял, что проблема была не в моем тесте, а в моих занятиях. Поэтому, если вы не можете протестировать класс, причина в том, что ваш класс не следует лучшим практикам. Хороший класс легко тестировать, но что делает его легким для тестирования?

  1. Вы должны использовать внедрение зависимостей:

Помимо облегчения вашей работы, DI также помогает вам писать тестируемые классы. Если вы вызываете конструктор внутри своего класса, его будет сложно имитировать¹ в тесте, хотя, когда вы помещаете все свои зависимости в конструктор, становится намного проще передать поддельный экземпляр в тестах. Затем вы можете проверить, правильно ли были вызваны эти поддельные экземпляры.

2. Необходимо соблюдать SRP:

Если у вашего класса много обязанностей, его, безусловно, будет сложно протестировать. Так что старайтесь, чтобы ваш урок был простым, коротким и имел только одну цель. Вы можете узнать больше о SRP по ссылке выше.

3. Вы не должны зависеть от фреймворка:

В некоторых случаях классы фреймворка трудно имитировать и сделать ваш класс менее пригодным для тестирования, поэтому старайтесь избегать зависимости от фреймворка в классах предметной области. Если вы не можете попытаться обернуть эту зависимость в другой класс, таким образом, в дополнение к упрощению теста, вы будете в большей безопасности, потому что, если эта зависимость станет устаревшей, вам просто нужно будет изменить ее в одном классе, что упростит обслуживание. простой.

Когда вы пишете лучший код, вы можете его протестировать, и качество кода значительно улучшается. Конечно, если вы будете следовать этим трем советам и писать тесты, ваше приложение будет все проще и проще поддерживать, понимать и избавляться от ошибок. Это всего лишь мое скромное мнение, основанное на моем опыте. Если у вас есть другая идея или вы хотите внести свой вклад в эту тему, пожалуйста, оставьте комментарий ниже. Я надеюсь, что это помогло вам.

¹Mock: макеты — это поддельные экземпляры сложных объектов, которые имитируют поведение реальных объектов. Подробнее о моках можно узнать здесь.