И снова я с темой инспекции кода, почитав книги по модульному тестированию.
Проект .NetFramework 4.6.1, фреймворк тестирования - nUnit.
У меня есть два простых класса в доменной модели: Order и OrderPosition:
Заказ:
using System;
using System.Collections.Generic;
using System.Linq;
namespace MyCompanyName.MyProjectName.Domain
{
public class Order
{
public Order(int id, DateTime created, IList orderPositions)
{
this.Id = id;
this.Created = created;
this.OrderPositions = orderPositions;
}
public int Id { get; }
public DateTime Created { get; }
public ICollection OrderPositions { get; }
public int PositionsCount
{
get { return this.OrderPositions.Count; }
}
public decimal OrderPrice
{
get { return this.OrderPositions.Sum(x => x.TotalPrice); }
}
}
}
Позиция заказа:
using System;
namespace MyCompanyName.MyProjectName.Domain
{
public class OrderPosition
{
private int _quantity;
private string _title;
public OrderPosition(int id, int orderId, string title, int quantity, decimal
unitPrice, decimal discount)
{
this.Id = id;
this.OrderId = orderId;
this.Title = title;
this.Quantity = quantity;
this.UnitPrice = unitPrice;
this.Discount = discount;
}
public int Id { get; }
public int OrderId { get; }
public string Title
{
get { return this._title; }
private set
{
if (value != null && value.Length > 20)
throw new ArgumentException(nameof(this.Title));
this._title = value;
}
}
public int Quantity
{
get { return this._quantity; }
private set
{
if (value < 1)
throw new ArgumentException(nameof(this.Quantity));
this._quantity = value;
}
}
public decimal UnitPrice { get; }
public decimal Discount { get; }
public decimal TotalPrice
{
get { return this.UnitPrice * this.Discount * this.Quantity; }
}
}
}
(Я несколько упростил пример из реального предложения, убрав справочник товаров,
вспомогательные поля чтобы сильно не раздувать код вопроса, но демо-приложение полностью
рабочее)
Попробовал написать юнит-тесты для этих классов.
Предварительно замечу по соглашению о наименовании классов: я использовал реже встречающийся
вариант, когда имя тестового класса идёт по шаблону <НазваниеТестируемого класса>Test_<тестируемый
метод>.
В первую очередь я набросал несколько тестов на автосвойства без всякой логики, например
Order.Id, Order.Created, OrderPosition.UnitPrice, OrderPosition.Discount.
Приведу лишь пару примеров, они все однотипные.
Для OrderPosition.UnitPrice такой тест:
using NUnit.Framework;
namespace MyCompanyName.MyProjectName.Domain.Tests.Unit
{
[TestFixture]
public class OrderPositionTests_UnitPrice : OrderPositionTestsBase
{
[Test]
public void Always_SetProp()
{
const decimal unitPrice = 123M;
var result = NewOrderPosition(1, 2, "asdf", 3, unitPrice, 0.1M);
Assert.AreEqual(unitPrice, result.UnitPrice);
}
}
}
Где в базовый класс вынесена логика инициализации объекта:
namespace MyCompanyName.MyProjectName.Domain.Tests.Unit
{
public class OrderPositionTestsBase
{
protected static OrderPosition NewOrderPosition(int id, int orderId, string
title, int quantity, decimal unitPrice, decimal discount)
{
return new OrderPosition(id, orderId, title, quantity, unitPrice, discount);
}
}
}
По рекомендациям Ошероува выносить инициализацию в фабричный метод.
Аналогично для Order.Id, там просто чуть больше данных конструируется:
using System;
using System.Collections.Generic;
using NUnit.Framework;
namespace MyCompanyName.MyProjectName.Domain.Tests.Unit
{
[TestFixture]
public class OrderTests_Id : OrderTestsBase
{
[Test]
public void Always_SetProp()
{
const int orderId = 1;
var result = NewOrder(orderId, new DateTime(), new List
{ NewOrderPosition(1, orderId, "asdf", 2, 1234M, 0.1M) });
Assert.AreEqual(orderId, result.Id);
}
}
}
И так же в базовый класс вынесена логика конструирования объекта:
using System;
using System.Collections.Generic;
namespace MyCompanyName.MyProjectName.Domain.Tests.Unit
{
public class OrderTestsBase
{
protected static Order NewOrder(int id, DateTime created, IList
orderPositions)
{
return new Order(id, created, orderPositions);
}
protected static OrderPosition NewOrderPosition(int id, int orderId, string
title, int quantity, decimal unitPrice, decimal discount)
{
return new OrderPosition(id, orderId, title, quantity, unitPrice, discount);
}
}
}
Далее я написал тесты для свойств, содержащих какую-никакую но логику.
Для поля "количество" я проверяю, что оно не может содержать нуль или отрицательные
числа:
using System;
using NUnit.Framework;
namespace MyCompanyName.MyProjectName.Domain.Tests.Unit
{
[TestFixture]
public class OrderPositionTests_Quantity : OrderPositionTestsBase
{
[Test]
public void ZeroValue_ThrowsArgumentException()
{
const int quantity = 0;
var ex = Assert.Throws(() => NewOrderPosition(1, 2,
"asdf", quantity, 1234M, 0.1M));
StringAssert.Contains(nameof(OrderPosition.Quantity), ex.Message);
}
[Test]
public void NegativeValue_ThrowsArgumentException()
{
const int quantity = -1;
var ex = Assert.Throws(() => NewOrderPosition(1, 2,
"asdf", quantity, 1234M, 0.1M));
StringAssert.Contains(nameof(OrderPosition.Quantity), ex.Message);
}
[Test]
public void PositiveValue_SetProp()
{
const int quantity = 1;
var result = NewOrderPosition(1, 2, "asdf", quantity, 1234M, 0.1M);
Assert.AreEqual(quantity, result.Quantity);
}
}
}
Для строки "наименование позиции товара" я контролирую длину строки:
using System;
using NUnit.Framework;
namespace MyCompanyName.MyProjectName.Domain.Tests.Unit
{
[TestFixture]
public class OrderPositionTests_Title : OrderPositionTestsBase
{
[Test]
public void NullValue_IsCorrect()
{
const string title = null;
var result = NewOrderPosition(1, 2, title, 2, 1234M, 0.1M);
Assert.IsNull(result.Title);
}
[Test]
public void ShortStringValue_SetsProp()
{
const string title = "asdf";
var result = NewOrderPosition(1, 2, title, 2, 1234M, 0.1M);
Assert.AreEqual(title, result.Title);
}
[Test]
public void TooLongValue_ThrowsArgumentException()
{
const string title = "123456789012345678901";
var ex = Assert.Throws(() => NewOrderPosition(1, 2,
title, 2, 1234M, 0.1M));
StringAssert.Contains(nameof(OrderPosition.Title), ex.Message);
}
}
}
После этого у меня остались расчётные поля.
Для OrderPosition это TotalPrice:
using NUnit.Framework;
namespace MyCompanyName.MyProjectName.Domain.Tests.Unit
{
[TestFixture]
public class OrderPositionTests_TotalPrice : OrderPositionTestsBase
{
[Test]
public void UnitPriceDiscontinued_Always_CalculatesTotalPrice()
{
var orderPosition = NewOrderPosition(1, 2, "", 2, 10M, 0.1M);
var totalPrice = orderPosition.TotalPrice;
Assert.AreEqual(2M, totalPrice);
}
}
}
Для Order это PositionsCount:
using System;
using System.Collections.Generic;
using NUnit.Framework;
namespace MyCompanyName.MyProjectName.Domain.Tests.Unit
{
[TestFixture]
public class OrderTests_PositionsCount : OrderTestsBase
{
[Test]
public void Always_ReturnsCount()
{
const int orderId = 1;
var orderPositions = new List
{
NewOrderPosition(1, orderId, "test", 1, 10M, 0.1M),
};
var order = new Order(orderId, new DateTime(), orderPositions);
var orderPositionsCount = order.PositionsCount;
Assert.AreEqual(orderPositions.Count, orderPositionsCount);
}
[Test]
public void Always_ReturnsCount2()
{
const int orderId = 1;
var orderPositions = new List
{
NewOrderPosition(1, orderId, "test1", 1, 10M, 0.1M),
NewOrderPosition(2, orderId, "test2", 3, 12M, 0.2M),
};
var order = new Order(orderId, new DateTime(), orderPositions);
var orderPositionsCount = order.PositionsCount;
Assert.AreEqual(orderPositions.Count, orderPositionsCount);
}
}
}
и OrderPrice:
using System;
using System.Collections.Generic;
using NUnit.Framework;
namespace MyCompanyName.MyProjectName.Domain.Tests.Unit
{
[TestFixture]
public class OrderTests_OrderPrice : OrderTestsBase
{
[Test]
public void UnitPriceDiscontinued_Always_ReturnsDiscontinuedPrice()
{
const int orderId = 1;
var order = new Order(orderId, new DateTime(), new List
{ NewOrderPosition(1, orderId, "test", 1, 10M, 0.1M) });
var orderPrice = order.OrderPrice;
Assert.AreEqual(1M, orderPrice);
}
}
}
На этом в принципе я решил подвести черту и провести ревью.
В первую очередь меня интересуют следующие вопросы:
Каких тестов не хватает?
Какие тесты нужно исключить или переделать?
Нужно ли как-то отдельно протестировать конструкторы? Если да, то как? Если нет -
то почему?
Есть ли какие-то рекомендации по наименованию тестов?
Покрывают ли тесты (особенно там где логика или расчёты) все возможные ситуации?
Какие есть замечания по самому коду тестов?
Также если есть какие-то замечания по самим тестируемым классам - тоже буду признателен
за обратную связь.
Ответы
Ответ 1
Громаднейший вопрос.
Что касается наименования тестов, то тут использовать правильнее наименования: class
Test_НаименованиеТестируемогоКласса (удобнее искать тесты при изменении класса)
Что касается наименования методов тестирования тут лучше пользоваться void Test_Наименование(метода/свойства)In(Входные
параметры, если нужны)Out(Что должны получить на выходе)(удобство при поиске нужного теста)
При большом количестве моделей данных удобно добавить категорию перед методом:[Category("модель")]void
Test_Наименование(метода/свойства)In... или даже перед классом - это дает удобство
при изменении модели, у вас есть возможность выбрать все тесты связанные с конкретной
моделью, такое удобно и при интеграционном тестировании
В Assert.AreEqual - добавить текст ошибки, типа Assert.AreEqual(a,b,"ожидалось {0},
в результате выполнения получили {1}",a,b); - такое удобно в дальнейшем для отладки
самого теста и конечно по прошествии большого времени вам этот текст поможет понять,
а что вы ожидали в итоге.
Иногда, чаще всего когда нужна отчетность по выполнению тестов, можно добавлять запись
логов, но тут надо быть крайне осторожными, однако в этом есть свои прелести, например,
можно автоматизировать отчет о проделанной работе над проектом, либо создать отчет
о не прошедших тестах, и получить в одном месте причины не прохождения тестов в проекте.
Однако с логгированием не стоит увлекаться, так как тесты должны быть простыми, и
легко разбираемыми.
Что нужно тестировать? Вопрос весьма спорный, так например я встречал в книгах, что
тестировать нужно все публичные методы и свойства, однако если у вас есть просто {get;set;},
что вы тогда будете тестировать? Однако у таких свойств есть обрабочики, наподобие
взять из свойства одного объекта и поставить в свойства другого, тогда этот обработчик
надо тестировать. Обязательно надо тестировать свойства с внутренней логикой установки
и получения на подобие: {get{...}set{...}}
На счет покрытия всех ситуаций, тут весьма интересный вопрос, Вы не БОГ! поэтому
предвидеть все ситуации в особо сложных случаях не сможете. Однако дополнять тесты
на основе пойманных багов. вам никто не запретит, и это даже правильнее, появился баг,
написали тест воспроизводящий баг, затем устранили, и протестировали.
Этот ответ не возможно считать полным, однако я постарался максимально четко передать
мой ход мыслей при создании тестов.
