Как записать модульный тест и не скучать в разработке проекта FOSS?

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

Проблемы могут заключаться в

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

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

TDD - не панацея. Это может быть реализовано ужасным образом. Он не должен становиться флажком в контрольном списке вашего проекта.

Модульные тесты должны следовать всем лучшим практикам производственного кода, таким как принцип DRY. Если вам надоест писать модульные тесты, вам также станет скучно писать производственный код.

Разработка через тестирование (TDD) может вам помочь, поскольку вы постоянно переключаетесь между написанием модульного теста, а затем небольшим производственным кодом.

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

Из-за природы проекта требуется изрядная автоматизация - найдите способ написать тест один раз для одной ОС / компилятора, а затем запустить его для всех остальных доступных опций.

напишите их, переходя от модульных тестов к коду, к модульному тесту к коду ... и так далее.

Учитывали ли вы nested_attributes для моделей рельсов? Вместо нескольких новых форм обратной связи, каждая из которых связана с аннотацией, можно использовать несколько редактируемых форм аннотации, в которых каждая аннотация включает поля для новой обратной связи. Идентификаторы созданных форм будут включать идентификаторы аннотаций, например edit _ annotation _ 16 .

Модель аннотации будет иметь связь со своими обратными связями, а также будет принимать вложенные атрибуты для них.

class Annotation < ActiveRecord::Base
  has_many :feedbacks
  accepts_nested_attributes_for :feedbacks
end

class Feedback < ActiveRecord::Base
  belongs_to :annotation
end

Затем можно добавить любое количество форм, по одной для каждой аннотации. Например, это то, что я пытался:

<% form_for @a do |form| %>
    Lyrics: <br />
    <%= form.text_field :lyrics %><br />
    <% form.fields_for :feedbacks do |feedback| %>
        Feedback: <br/>
        <%= feedback.text_field :response %><br />
    <% end %>
    <%= form.submit "Submit" %>
<% end %>

<% form_for @b do |form| %>
    Lyrics: <br />
    <%= form.text_field :lyrics %><br />
    <% form.fields_for :feedbacks do |feedback| %>
        Feedback: <br/>
        <%= feedback.text_field :response %><br />
    <% end %>
    <%= form.submit "Submit" %>
<% end %>

И быстрый и грязный контроллер для вышеприведенного вида редактирования:

class AnnotationsController < ApplicationController
  def edit
    @a = Annotation.find(1)
    @a.feedbacks.build
    @b = Annotation.find(2)
    @b.feedbacks.build
  end

  def update
    @annotation = Annotation.find(params[:id])
    @annotation.update_attributes(params[:annotation])
    @annotation.save!
    render :index
  end
end

записать их прыжки от единичных тестов к коду к единичному тесту к коду... и так далее.

Лично я нахожу написание кода, который, как я знаю, очень волнует. Но если вы не хотите, чтобы вам было скучно писать единичные тесты, то вам нужно будет культивировать увлечение для отладки.

Чтобы быть серьезным, если вы считаете, что тесты на записи скучны и медленны, вам действительно нужно переосмыслить, как вы пишете их. Я предлагаю вам изучить использование Test Driven Development. Запишите тесты на языке программирования и запустите их автоматически. Используйте отзывы тестов для формирования кода.

Существуют фреймворки Test First для практически любого языка, который вы хотите упомянуть, вдохновленные работой Кента Бека и Эриха Гаммы с JUnit. Статья Википедии на TDD имеет больше информации, включая полезную ссылку на список фреймворков, организованных по языку. Подробнее .

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