Пример TDD для бизнес-приложений

Question

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

Мы предупреждаем о том, что не следует тестировать платформу или базу данных. Хороший дизайн пользовательского интерфейса не подходит для тестирования, не относящегося к человеку. Взаимодействие с пользовательским интерфейсом вообще исключено в рамках MVC. Во многих приложениях что осталось? 37signals говорит о всестороннем модульном тестировании, но в таких приложениях, как Basecamp или Backpack, какие именно типы тестируются с помощью соответствующих модульных тестов? Что будет означать 100% покрытие кода в этом сценарии?

РЕДАКТИРОВАТЬ: я не разрушаю приложения, такие как Backpack - они потрясающие, но работа, похоже, направлена ​​больше на дизайн и взаимодействие, а не на сложную логику (фактически, они поддерживают эту идею). В тех областях этого приложения, где CRUD и иерархия какого объекта связаны с тем, что в значительной степени покрывает его, является ли соответствующее количество модульных тестов нулевым? Является ли точка тестирования в этом случае другой копией кода проверки (обязательно, регулярное выражение и т. Д.)?

Answer 1

TDD для бизнес-приложений работает следующим образом.

1. Запишите бизнес-требования.

2. Запишите тест для этого требования.

3. Введите код, который проходит тест.

Хитрость в том, что существует множество ненужных некоммерческих требований, которые не требуют тщательного тестирования.

• «Сохранение в базе данных» не является бизнес-требованием. Это технический.

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

• «резервное копирование» не является бизнес-требованием; это безопасность или непрерывность бизнеса или что-то в этом роде.

Рассмотрим конкретный пример.

Требование - «Вы не можете брать книги, пока не заплатите штрафы».

Тесты.

1. Попытка одолжить книгу со штрафом.

2. Попытка одолжить книгу без штрафа.

код.

class FinesNotPaid( unittest.TestCase ):
    def setUp( self ):
        # load some fixtures with users, books and fines outstanding.
    def test_should_not_checkout_book( self ):
        x = TheCheckoutClass()
        x.checkoutBook( someBook )
        self.fail( "Should have thrown error" )

class FinesPaid( unittest.TestCase ):
    def setUp( self ):
        # load some fixtures with users, books and fines paid.
    def test_should_not_checkout_book( self ):
        x = TheCheckoutClass()
        x.checkoutBook( someBook )
        self.success(  )

class NoFines( unittest.TestCase ):
    etc.

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

Ваши CRUD-правила являются бизнес-правилами. Вы должны проверить их. Однако вам не нужно тестировать каждую функцию, связанную с базой данных. Вам нужно несколько "я могу создать и сохранить объект?" тесты. Вы должны верить, что ORM, уровень доступа к данным и база данных действительно работают. Вы не пишете тесты для исчерпывающего тестирования встроенных функций ORM.

Покрытие кода (100%, 80% или 10%) в значительной степени бессмысленно. Является ли программное обеспечение, тесты которого покрывают 80% кода, на самом деле на 20% более вероятным сбоем? Это не работает таким образом. Тестирование каждой строки кода не охватывает все логические пути, поэтому перестаньте беспокоиться и начните тестирование.

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

Answer 2

Вы проверяете, чтобы убедиться, что бизнес-логика (во многих приложениях это слой «сервис» или «логика») соответствует описанию бизнес-пользователей о том, как на самом деле работает бизнес. Вы проверяете, чтобы убедиться, что, например, только потому, что вы добавляете 6% налог с продаж ко всем покупкам из Пенсильвании, вы также не даете бонус 6%, когда дарите кому-то подарочную карту.

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