Доступ к DreamSpark по студенческому билету для украинских студентов и аспирантов

Если ты студент и у тебя есть студенческий билет, то ты можешь получить ряд продуктов бесплатно:
Visual Studio 2008
Visual Studio 2005
XNA Game Studio 3
SQL Server 2008 Developer
Windows Server 2003
Windows Server 2008 Standard
Expression Studio 2


Подробности тут:
Доступ к DreamSpark по студенческому билету для украинских студентов и аспирантов

Необычный подход к написанию юнит тестов

Обнаружил довольно необычный подход к написанию юнит тестов у автора вот этого поста:
Test Driven Design и Test First Development -- в чем разница?

Меня привлекло то, что тест класс представляет из себя наследник тестируемого класса.

Приведу пример классического и альтернативного подхода (пример из документации NUnit).

Тестируемый класс:

namespace bank
{
 public class Account
 {
   private float balance;
   public void Deposit(float amount)
   {
     balance+=amount;
   }

   public void Withdraw(float amount)
   {
     balance-=amount;
   }

   public void TransferFunds(Account destination, float amount)
   {
   }

   public float Balance
   {
     get{ return balance;}
   }
 }
}

Тест, написаный при помощи "классического" подхода:

namespace bank
{
 using NUnit.Framework;

 [TestFixture]
 public class AccountTest
 {
   [Test]
   public void TransferFunds()
   {
     Account source = new Account();
     source.Deposit(200.00F);
     Account destination = new Account();
     destination.Deposit(150.00F);

     source.TransferFunds(destination, 100.00F);
     Assert.AreEqual(250.00F, destination.Balance);
     Assert.AreEqual(100.00F, source.Balance);
 
   }
 }
}

Тест, написанный с помощью альтернативного подхода с наследованием:

namespace bank
{
 using NUnit.Framework;

 [TestFixture]
 public class AccountTest : Account
 {
   [Test]
   public void TestTransferFunds()
   {
     this.Deposit(200.00F);
     Account destination = new Account();
     destination.Deposit(150.00F);

     this.TransferFunds(destination, 100.00F);
     Assert.AreEqual(250.00F, destination.Balance);
     Assert.AreEqual(100.00F, this.Balance);
   }
 }
}

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


Лично у меня возникает вопрос. А стоит ли вообще так писать тесты?

У меня сходу возникли следующие мысли насчет альтернативного подхода:
+ Наследование позволяет протестировать protected методы
+ Я могу написать helper-методы в тест классе, который будет активно работать с protected методами и свойствами
- Наследование дает бОльшую связность между тестовым и тестируемым классом
- Наследование скорее всего завяжет мне руки в SetUp/TearDown методах
- Если класс sealed, то о подходе с наследованием можно забыть
- Когда я пишу классический тест-метод, то я получаю лаконичную документацию к своему коду в виде маленьких примеров
- Когда я пишу классический тест-метод, то я использую класс точно так же как это делает production-код
- У класса Account будет аж два клиента - production code and unit tests, что как правило будет положительно отражаться на его интерфейсе


Очень интересны ваши мнения на этот счет.

Тест. Какой вы ученый?

Очередное баловство на тему тестов.

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

Как правило это играет мне на руку, хотя иногда все-же делает меня занудой. :)

О, да вы - физик.

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

Пройти тест