Можно ли улучшить этот тест MSpec? - PullRequest
Новая
       44

Можно ли улучшить этот тест MSpec?

3 голосов
/ 09 августа 2011

Будучи новичком в BDD и MSpec, я все еще не уверен в том, что такое лучшие практики и хорошие привычки, связанные с BDD в целом и особенно с MSpec.

Можно ли улучшить следующий пример? Это следует за лучшими методами и хорошими привычками?

  1. Нормально ли присвоены имена моим спецификационным классам и поведению?
  2. Должен ли я использовать поведения в этом сценарии или использовать общий базовый класс для классов спецификации?
  3. Можно ли не иметь здесь Establish? 1011 *
  4. Должен ли я использовать статические фабричные методы (TestData методы) для получения тестовых данных или данные должны быть созданы в самой спецификации?
  5. Вместо того, чтобы проверять каждое свойство в поведении, я мог бы использовать result.Equals(), но тогда я бы проверял две вещи, что нехорошо, верно?

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

[Subject(typeof(DataItemReader))]
public class When_reading_a_DataItem_from_stream
{
    Because of = () =>
    {
        using (var reader = new DataItemReader(
            new MemoryStream(TestData.GetNormalDataItemAsByteArray()), Encryption.None))
        {
            result = reader.ReadItem();
        }
    };

    Behaves_like<DataItemReader_that_reads_correctly> behavior;

    protected static DataItem result;
}

[Subject(typeof(DataItemReader))]
public class When_reading_a_DataItem_from_encrypted_stream
{
    Because of = () =>
    {
        using (var reader = new DataItemReader(
            new MemoryStream(TestData.GetNormalDataItemAsByteArrayEncyrpted()), Encryption.Default))
        {
            result = reader.ReadItem();
        }
    };

    Behaves_like<DataItemReader_that_reads_correctly> behavior;

    protected static DataItem result;
}

[Behaviors]
public class DataItemReader_that_reads_correctly
{
    protected static DataItem result;

    It should_read_the_correct_DataItem = () =>
    {
        var testItem = TestData.GetNormalDataItem();
        result.Property1.ShouldEqual(testItem.Property1);
        result.Property2.ShouldEqual(testItem.Property2);
        result.Property3.ShouldEqual(testItem.Property3);
    };
}

1 Ответ

6 голосов
/ 09 августа 2011

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

С точки зрения одного разработчика:

  1. Мой регистр и имя соответствуют тому, что читается в коде. Хорошая вещь о выдержках HTML - это то, что вы получите читаемые спецификации в конце. Многое из того, что я прочитал, сосредоточено на том, чтобы иметь все строчные буквы или что-то подобное; тем не менее, я произношу свое слово так же, как ваше: правильный, читаемый корпус.

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

  3. Establish всегда означало «настройку среды перед моим тестом». В двух приведенных вами примерах я, вероятно, переписал бы это так: 

    Establish context = () => var reader = 
       new DataItemReader(new MemoryStream(     
       TestData.GetNormalDataItemAsByteArray()),                               
       Encryption.None));

Because of = () => result = reader.ReadItem();

Cleanup after = () => reader.Dispose();

    Так как спецификация фокусируется на DataItem, «который читает», действие или Because - это просто так. Опять же, вопрос предпочтений.

  4. Я использую статические фабрики многократного использования, где у меня либо заглушки, созданные вручную, либо у меня есть движок-заглушка / насмешка (например, FakeItEasy http://code.google.com/p/fakeiteasy/). На мой взгляд, содержание / создание заглушек не имеет никакого отношения к реальной test и должны восприниматься заглушками как черный ящик (вот почему мы пишем тесты, верно?).

  5. Я сосредотачиваюсь на каждом объекте индивидуально (если он у вас есть), чтобы он соответствовал моим ожиданиям. Если вы когда-нибудь переопределите Equals, вы, возможно, будете проверять равенство для свойств, которые не являются частью спецификаций или не имеют отношения к делу.

Я не уверен, что есть какие-то руководящие «лучшие практики» (на сайте github есть несколько советов: https://github.com/machine/machine.specifications#readme). Я обнаружил, что некоторые из моих стилей кодирования изменились, глядя на другие проекты используя MSpec и наблюдая за тем, как они обрабатывают свои спецификации.

...