Контакт с TDD / усталость Поблочного тестирования

Таким образом, я привыкаю к TDD, но я столкнулся с неожиданной проблемой: я становлюсь действительно усталым от 100%-го покрытия кода. Тесты становятся более утомительными для записи, чем сам код, и я не уверен, делаю ли я его правильно. Мой вопрос: Какие вещи Вы, как предполагается, тестируете, и какими вещами является излишество?

Например, у меня есть тест следующим образом, и я не уверен если его полезное вообще. Что я, как предполагается, делаю так, чтобы я все еще следовал за TDD, но не уставал от записи тестов?

describe 'PluginClass'

    describe '.init(id, type, channels, version, additionalInfo, functionSource, isStub)'

        it 'should return a Plugin object with correct fields'

            // Create test sets
            var testSets = new TestSets()
            var pluginData = {
                'id'                : null,
                'type'              : null,
                'channels'          : null,
                'version'           : null,
                'additionalInfo'    : null,
                'functionSource'    : null,
                'isStub'            : true
            }
            testSets.addSet({ 'pluginData' : pluginData })
            var pluginData = {
                'id'                : "testPlugin1",
                'type'              : "scanner",
                'channels'          : ['channelA', 'channelB'],
                'version'           : "1.0",
                'additionalInfo'    : {'test' : "testing"},
                'functionSource'    : "function () {alert('hi')}",
                'isStub'            : false
            }
            testSets.addSet({ 'pluginData' : pluginData })

            for (var t = 0; t < testSets.getSets().length; t ++) {
                var aTestSet = testSets.getSet(t)

                var plugin = new Plugin().init( aTestSet.pluginData.id,
                                                aTestSet.pluginData.type,
                                                aTestSet.pluginData.channels,
                                                aTestSet.pluginData.version,
                                                aTestSet.pluginData.additionalInfo,
                                                aTestSet.pluginData.functionSource,
                                                aTestSet.pluginData.isStub  )

                plugin.getID().should.eql aTestSet.pluginData.id
                plugin.getType().should.eql aTestSet.pluginData.type
                plugin.getChannels().should.eql aTestSet.pluginData.channels
                plugin.getVersion().should.eql aTestSet.pluginData.version
                plugin.getAdditionalInfo().should.eql aTestSet.pluginData.additionalInfo
                eval("fn = " + aTestSet.pluginData.functionSource)
                JSON.stringify(plugin.getFunction()).should.eql JSON.stringify(fn)
                plugin.getIsStub().should.eql aTestSet.pluginData.isStub
            }

        end

    end

end
7
задан Chetan 8 August 2010 в 03:55
поделиться

5 ответов

Конечно, вышеупомянутый «тест» во многих отношениях является излишним. Он слишком длинный и сложный, трудно читаемый и слишком много утверждает. Я с трудом могу представить, как это могло появиться в результате процесса TDD. Неудивительно, что вы устаете от подобных вещей ...

Разработка через тестирование означает: вы должны идти маленькими шагами, где каждый шаг является отдельным тестом, утверждает только одно и не содержит абсолютно никакой логики ( т.е. нет для , if / else или аналогичных ...). Таким образом, приведенный выше код приведет к примерно 4-6 отдельным тестовым методам, которые вы затем реализуете один за другим. Сначала подтвердите правильную инициализацию свойства (с разными значениями по мере необходимости), затем убедитесь, что методы работают должным образом, и так далее ...

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

В итоге: Иметь тесты практически для всего (100% покрытие) - это не излишество, но, безусловно, проблема иметь тесты, как в вашем примере.

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

HTH!
Томас

7
ответ дан 6 December 2019 в 19:31
поделиться

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

Так что действуйте.

3
ответ дан 6 December 2019 в 19:31
поделиться

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

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

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

2
ответ дан 6 December 2019 в 19:31
поделиться

Ваш тест пытается одновременно проверить слишком много вещей. Разделите его на несколько тестов и рефакторинг вашего тестового кода (да, вспомогательные методы разрешены).

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

1
ответ дан 6 December 2019 в 19:31
поделиться

Похоже, вы

  • тестируете конструкторы с простым присваиванием членов. Это перебор, если в конструкторе нет нетривиальной логики. Вместо этого полагайтесь на это, чтобы пройти тестирование как часть некоторых других тестов, в которых будут использоваться члены.
  • сравнение равенства между двумя объектами значений. Переопределите / определите проверку равенства для типа / класса плагина, переопределив метод equals. поэтому plugin.should.eql expected_plugin должен быть единственным утверждением
  • , также рассмотрите возможность использования вспомогательных объектов для создания сложных тестовых данных.
0
ответ дан 6 December 2019 в 19:31
поделиться
Другие вопросы по тегам:

Похожие вопросы: