Использование TDD с методологией Agile Scrum

Высокий уровень к низкому уровню

После того, как вы сократите свою работу до разумного объема работы для спринта, вот полезный способ написать пользовательские истории для Jira или чего-то еще, что вы используете, чтобы ваша команда могла легко понять требования к программному обеспечению.

Начните с каркасов

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

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

Как сформулировать пользовательские истории

Для объемной работы сформулируйте каждый тикет как пользовательскую историю следующим образом:

«Как ____, я хочу ___, чтобы ____»

Например: «Как Пользователь, я хочу иметь возможность сортировать свой список ресторанов по расстоянию до ближайшего ко мне, чтобы я мог дойти до ближайшего ресторана пешком».

Первое поле предназначено для определения типа Пользователя, второе поле — это цель Пользователя, а третье поле — это польза для Пользователя.

Критерии приемлемости

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

Добавьте его в качестве описания своей пользовательской истории со следующей формулировкой:

"Должно ____"

Например: «Список ресторанов должен располагаться от ближайшего к самому дальнему, когда включен фильтр расстояния».

Как правило, лучше всего перечислить их на высоком уровне ожидаемых результатов с точки зрения пользователя:

«Критерии приемки:

  • Он должен упорядочивать список ресторанов от ближайшего к самому дальнему, когда установлен фильтр расстояния.
  • Он должен иметь исходный порядок сортировки с отключенным фильтром расстояния.
  • Он должен иметь разбивку на страницы с отображением не более 10 элементов на странице.
  • Он должен отображать расстояние до ресторана в правом нижнем углу div, отображающего каждый ресторан.
  • …”

Модульные тесты

Часто бывает полезно начать с функции, название которой близко к исходным критериям приемлемости для первого неудавшегося модульного теста.

import { sortByDistance } from './restaurants'
describe('sortByDistance()',()=> {
  it('should be a function',()=>{
    expect(sortByDistance).to.be.a('function');
  });
  it('should accept an array as an argument',()=>{
  
  });
  it('should order the array of restaurants from closest to farthest when the distance filter is checked',()=> {

  });
});

В типичном стиле TDD, это когда вы продолжите писать производственный код, чтобы пройти тест. Затем идите вперед и назад, сначала написав свой неудачный тест, а затем написав производственный код, чтобы он прошел.

В приведенном выше примере производственный код будет записан в файле restaurant.js в том же каталоге.

Вывод

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