Процедуры модульного тестирования (в отличие от функций) - PullRequest
2 голосов
/ 11 мая 2009

Я новичок в модульном тестировании и хотел бы знать, как бы вы пошли о модульном тестировании процедуры (в данном случае процедура - функция, которая «что-то делает», а не «возвращает что-то».

Я знаю, что общая идея тестирования функции, которая возвращает ответ, выглядит примерно так:

assert(yourfunction(sample, inputs) == expected_answer);

но мне интересно, как это будет работать, если что-то не вернется или просто вернет код состояния.

Ответы [ 4 ]

2 голосов
/ 11 мая 2009

Вы должны быть в состоянии проверить, что он делает. Например, ваша процедура добавляет что-то в коллекцию? Установить свойство? Создать файл?

Что бы это ни было, предположительно это изменение заметно как-то . Вам просто нужно разобраться, как проверить этот эффект. Конечно, это легче сказать, чем сделать иногда, поэтому функциональный подход легче проверить, когда он подходит :) В частности, эффекты, которые изменяют внешние ресурсы (файловая система, базы данных и т. Д.) И эффекты, которые зависят от на внешних ресурсах (так же) сложнее протестировать, чем те, которые меняют ситуацию только на "локальный" путь.

1 голос
/ 11 мая 2009

Для процедур «что-то делать» обычно включает вызовы API или другие манипуляции с объектами.

Например, процедура может записать строку в файл. Он использует вызовы File I / O API (или объект File IO), чтобы выполнить «запись строки».

То, что вы хотите сделать, это создать «фиктивный» объект, который будет заменять Файл. Объект Mock обладает достаточной функциональностью, чтобы собрать результаты теста и сделать их видимыми для утверждения. Не перезаписывайте свои ложные объекты, это крысиная нора потерянного времени.

В Python мы делаем такие вещи.

class MockFile( object ):
    def __init__( self, aFileName, aMode ):
        self.name= aFileName
        self.mode= aMode
        self.buffer= None
    def write( self, aRow ):
        self.buffer= str(aRow)

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

class TestSomeProcedure( unittest.TestCase ):
    def testWrite( self ):
        mockFile= MockFile( "name", "w" )
        theProcedureImTesting( args, args, args, mockFile )
        self.assertEquals( "The Row It Was Supposed to Write\n", mockFile.buffer )
1 голос
/ 11 мая 2009

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

0 голосов
/ 11 мая 2009

Есть много разных случаев:

Дело 1:

    public class A
    {
      public void Foo()
      {
        Init();
      }

      protected virtual void Init()
      {
        Do something;
      }
    }

    [TestFixture]
    public class ATests
    {
      [Test]

      public void Foo_test()
      {
         A aStub = new A_Stub();
         aStub.Foo();
         Assert.IsTrue(aStub.wasInit);
      }

       public class A_Stub : A
       {
          public bool wasInit;

          protected override void Init()
          {
            wasInit = true;
          }
       }
  }

Случай 2: Когда ваш метод зависит от другого объекта, вместо этого выполняется член, принадлежащий к тому же классу. В этом случае я бы рекомендовал использовать Mock Framework. Я лично использую Rhino.Mocks. Вы можете перейти по этой ссылке, чтобы увидеть Rhino.Mocks примеры .

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