Должен ли я использовать насмешку для следующего примера

Question

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

[TestMethod()]
        public void NextSaturdayTest()
        {
            DateTime date = new DateTime(); 
            date = DateTime.Parse("2010-08-14");
            DateTime expected = new DateTime(); 
            expected = DateTime.Parse("2010-08-21");
            DateTime actual;
            actual = DateExtensions.NextSaturday(date);
            Assert.AreEqual(expected, actual);

            date = DateTime.Parse("2010-08-19");
            expected = DateTime.Parse("2010-08-21");
            actual = DateExtensions.NextSaturday(date);
            Assert.AreEqual(expected, actual);
        }

Во-первых, это хорошие практики тестирования? Во-вторых, в чем преимущество использования фиктивной инфраструктуры для создания этого теста?

Дайте мне знать, могу ли я предложить больше информации.

Спасибо за любые мысли

Answer 1

Во-первых, не делайте этого:

DateTime date = new DateTime();
date = DateTime.Parse("2010-08-14");

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

Во-вторых, хороший тест проверяет одну вещь.У вас может быть несколько тестов, таких как ReturnsCorrectNextSaturdayGivenAWednesday, ReturnsCorrectNextSaturdayWhenCrossesEndOfMonth и ReturnsCorrectNextSaturdayWhenCrossesEndOfYear.

И, наконец, нет причин для насмешек.Было бы уместно использовать макет, если ваши DateExtensions вызваны в другой компонент (скажем, в базу данных), и вы хотите подделать этот вызов.Таким образом, вместо тестирования DateExtensions + Data Access, вы будете тестировать только DateExtensions, и когда он вызывает слой доступа к данным, это будет имитировать, что ваш тест настроен.

Answer 2

Насмешка используется для удовлетворения зависимостей.

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

public class UserService
{
    public UserService(IDataLayer layer) {}
    public User GetById(int id)
} 

При тестировании вы не хотите проводить тестирование по базе данных.Это затрудняет предоставление данных и проверку результатов.Вместо этого вы издеваетесь над объектом IDataLayer, чтобы иметь возможность вручную предоставить пользователя для UserService.Это значительно облегчает проверку того, что UserService делает то, что должен.

Что касается вашего метода тестирования.Я бы разбил его на два метода, так как вы запускаете два разных теста (хотя для одного и того же метода)

Answer 3

Я думаю, что ты в порядке без насмешек в этом случае.Обычно вы издеваетесь над какой-то зависимостью (например, если у вас есть DateProvider или что-то в этом роде), но в этом случае использование DateTime напрямую мне подходит.

Я бы, однако, немного очистил ваш тест.Вам следует придерживаться одного теста для каждого метода, потому что, если этот метод не пройден, вы будете знать, ПОЧЕМУ он потерпел неудачу, вместо того, чтобы проверять утверждения и задаться вопросом, прошли ли остальные из них.

[TestMethod()]
public void NextSaturdayReturnsCorrectValueStartingFromASaturday()
{
    DateTime date = DateTime.Parse("2010-08-14");

    DateTime expected = DateTime.Parse("2010-08-21");
    DateTime actual = DateExtensions.NextSaturday(date);

    Assert.AreEqual(expected, actual);
}

[TestMethod()]
public void NextSaturdayReturnsCorrectValueWithinTheSameWeek() 
{
    DateTime date = DateTime.Parse("2010-08-19");
    DateTime expected = DateTime.Parse("2010-08-21");
    DateTime actual = DateExtensions.NextSaturday(date);

    Assert.AreEqual(expected, actual);
}

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

Answer 4

В этом случае имитирующий фреймворк не нужен и, следовательно, не должен использоваться.

Ваш тест вполне оправдан.Я бы лично добавил большую часть разбора даты для лучшей читаемости:

[TestMethod()]
    public void NextSaturdayTest()
    {
        DateTime actual = DateExtensions.NextSaturday(DateTime.Parse("2010-08-14"));
        Assert.AreEqual(DateTime.Parse("2010-08-21"), actual);

        actual = DateExtensions.NextSaturday(DateTime.Parse("2010-08-19"));
        Assert.AreEqual(DateTime.Parse("2010-08-21"), actual);
    }