Как повторно использовать утверждения и/или настройки в тестах xBehave?

Question

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

"When CreateBidCommand is executed" 
     .x(() => 
     { 
      _createBidCommand = new CreateBidCommand(_client, _bidYear, _optionNumber, 
       _underwritingLicenseFiling, _underwriter, _bidType, _description, _claimsApplicationType); 
      _commandDispatcher.Send(_createBidCommand); 
     }); 
    "Then Bid should be created" 
     .x(() => 
     { 
      _bid = _bidRepository.FindByBidNumber(_client, _bidYear, _optionNumber); 
      Assert.NotNull(_bid); 
     }); 
    " with description" 
     .x(() => Assert.Equal(_bid.Description, _description)); 
    " with Client" 
     .x(() => Assert.Equal(_client.Id, _bid.Client.Id)); 
    " with OptionNumber" 
     .x(() => Assert.Equal(_bid.OptionNumber, _optionNumber)); 
    " with BidType" 
     .x(() => { Assert.Equal(_bid.BidType.Code, _bidType.Code); }); 
    " with ClaimsApplicationType " 
     .x(() => Assert.Equal(_bid.ClaimsApplicationType.Code, _claimsApplicationType.Code)); 
    " with RegulatoryBody" 
     .x(() => Assert.Equal(_bid.RegulatoryBody,_underwritingLicenseFiling.RegulatoryBody)); 
    " with Underwriter" 
     .x(() => Assert.Equal(_bid.Underwriter, _underwriter)); 
    " with UnderwritingFirm" 
     .x(() => Assert.Equal(_bid.UnderwritingFirm,_underwritingLicenseFiling.UnderwritingFirm)); 
    "Then one and only one BidProposal should be created" 
     .x(() => Assert.True(_bid.BidProposals().Count() == 1)); 
    " with BaseForm" 
     .x(() => Assert.Equal(_underwritingLicenseFiling.BaseForm, _bid.LatestProposal().BaseForm)); 
    "Then one and only one ClientPolicy should be created" 
     .x(() => 
     { 
      var clientPolicies = _clientPolicyRepository.FindByBidId(_bid.Id); 
      Assert.Equal(clientPolicies.Count(), 1); 
     }); 
    "Then ProductionSchedule should have only one step" 
     .x(() => Assert.True(_bid.LatestProposal().ProductionSchedule.Count() == 1)); 
    " and it should be Initial creation" 
     .x(() => 
       Assert.True(_bid.LatestProposal().ProductionSchedule.ElementAt(0).BidStatusType.Code == 
          BidStatusTypeCode.InitialCreation)); 

Answer 1

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

// (Type declared here just to make it obvious) 
FakeBid _expectedBid = new FakeBidBuilder().WithClient(_client) 
            .WithBidYear(_bidYear) 
            // etc. 
            .Build(); 

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

При вызове команды, теперь вы можете передать ему параметры этого поддельного ставка:

_createBidCommand = new CreateBidCommand(
     _expectedBid.Client, 
     _expectedBid.BidYear, 
     // etc. 
     ); 

И теперь вы положили сличитель на классе FakeBid:

AssertTrue(_expectedBid.Matches(_bid)); 

Любые внеплановые проверки могут быть проверены отдельно.

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

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

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

Answer 2

Я бы сделал это, создав тестовую DSL, которая делает стандартные утверждения для меня, например.

"When CreateBidCommand is executed" 
     .x(() => 
     { 
      _createBidCommand = new CreateBidCommand(_client, _bidYear, _optionNumber, 
       _underwritingLicenseFiling, _underwriter, _bidType, _description, _claimsApplicationType); 
      _commandDispatcher.Send(_createBidCommand); 
     }); 
    "Then Bid should be created" 
     .x(() => 
     { 
      _bid = _bidRepository.FindByBidNumber(_client, _bidYear, _optionNumber); 
      Assert.NotNull(_bid); 
     }); 
    "And the bid should have the properties descibed by the command" 
     .x(() => AssertBid(_bid, _description, _client, ...)); 
    ... 

Где AssertBid это метод в моем тестировании DSL.