Mockito и Behavior Driven Development
1798  Screamer [Off]
 საქარტველოს გაუმარჯოს
(23.12.2014 / 21:44)
Код и не должен под них писаться. А вот гибкость какая-никакая должна быть.
Вот возьмём простой заезженный пример:

  1. class One
  2. {
  3.     private $two;
  4.  
  5.     public function __construct()
  6.    {
  7.         $this->two = new Two();
  8.    }
  9. }
  10.  
  11. class Two
  12. {
  13. }
  14.  
  15. $one = new One();


  1. class One
  2. {
  3.     private $two;
  4.  
  5.     public function __construct(Two $two)
  6.    {
  7.         $this->two = $two;
  8.    }
  9. }
  10.  
  11. class Two
  12. {
  13. }
  14.  
  15. $one = new One(new Two());

Код в комментариях не нуждается. И так очевидно, какой подход лучше.
Если пейсатель не задумывался над тем, что может понадобиться подменить реализацию, то при написании тестов уж точно понадобится внедрить мок. И если этот пейсатель пишет тесты, то считай, что некоторые проблемы он уже избежал.
Возможно притянуто за уши и вообще я херню сморозил, но я не знаю как еще можно наглядно объяснить то, что я хотел сказать в том посте.
553  Oak [Off]
 Эль Презеденте
(23.12.2014 / 18:41)
При условии, что система спроектирована грамотно и замОчить объекты не составляет никакого труда.Мне кажется неприятным подход, при котором код пишется под тесты.
1314  Koenig (FMod) [Off]
 Магистр Мёда
(22.12.2014 / 20:15)
Screamer, я же любитель гг
1798  Screamer [Off]
 საქარტველოს გაუმარჯოს
(22.12.2014 / 18:41)
Koenig, Мугога. Скажи это разработчикам крупных проектов. Без тестирования там никуда. Кстати в похапе есть для этого соответствующие инструменты. Например Behat и Codeception. От последнего я был просто в восторге. Есть интеграция с кучей фреймворков и библиотек. К примеру, когда тестируешь что-то через selenium, оно даже скриншот провалившегося теста делает. Это же вообще круто. Гг.
1314  Koenig (FMod) [Off]
 Магистр Мёда
(22.12.2014 / 07:40)
полезно, но для пхп обычно все сводится к echo print_r var_dump
1  aNNiMON (SV!) [Off]
 let live
(21.12.2014 / 20:32)
Naik, интерфейс можно тестировать. В стандартном пакете есть нагрузочное тестирование интерфейсов, MonkeyTest кажется. Проверяет отзывчивость тыкая кучу раз в секунду по экрану и нажимая разные клавиши.
Есть ещё сторонние разработки, там реальное тестирование - пишешь скрипты, мол в это поле введи 1234, потом нажми Меню, выбери пункт и сравни результат с TextView с id таким-то с ожидаемым значением и оно автоматически делает.
Изм. aNNiMON (21.12 / 20:34) (2)
275  Naik [Off]
(21.12.2014 / 20:24)
vl@volk, до меня только дошло :gg: Просто я думал, как мне помогут тесты в приложении на андроид например.. А их удобно использовать разве что для проверки текстовых или числовых данных. Интерфейс то никак автоматически не потестируешь
3789  vl@volk [Off]
 знает толк
(21.12.2014 / 17:34)
Naik, ну да, об этом в начале статьи написано.
275  Naik [Off]
(21.12.2014 / 15:43)
Кажется понял для чего нужно использовать тесты. Для проверки результатов работы программы, которая получает что-то на вход и мы заранее знаем что она должна вернуть. Это заменяет постоянное ручное тестирование.

Но в данной статье показано что-то очень сильно напоминающее обычный дебаг.
107  Freddy [Off]
(21.12.2014 / 00:00)
Screamer, особой разницы я между юнит-тестированием и функциональным не замечал, для меня самое главное - это сценарии теста придумать. А так да, на практике у нас получалось мало юнит-тестов (для нескольких нетривиальных функций-хелперов), в основном тесты были интеграционные, функциональные и, чуть меньше, системные.
Всего: 32
<< 1 2 3 4 >>
К записи
Java
Категории

Мы в соцсетях

tw tg yt gt