每個人都熟悉 TDD 的典型作業流程：撰寫失敗的測驗，通過撰寫足夠的代碼使測驗通過，重構代碼，然后重復。這通常用創造的“紅、綠、重構”來捕捉。
TDD 作業流最自然地與單元測驗一起實踐。但是，每個人也都知道，這些還不夠，一個好的代碼庫還應該包含在集成和端到端測驗中。這些其他型別的測驗是否可以或應該作為 TDD 作業流程的一部分來實施？為什么或者為什么不？如果是這樣，它們在典型敏捷團隊的開發作業流實踐中的位置如何？
uj5u.com熱心網友回復：
是的，您可以使用Outside-in TDD，從邊界開始，針對應用程式的“表面積”撰寫粗粒度測驗。之后，您可以通過集成和單元測驗來充實行為。
下面是一個針對 REST API 的邊界測驗示例，用 C# 撰寫：
[Fact]
public async Task ReserveTableAtNono()
{
using var api = new SelfHostedApi();
var client = api.CreateClient();
var at = DateTime.Today.AddDays(434).At(20, 15);
var dto = Some.Reservation.WithDate(at).WithQuantity(6).ToDto();
var response = await client.PostReservation("Nono", dto);
await AssertRemainingCapacity(client, at, "Nono", 4);
await AssertRemainingCapacity(client, at, "Hipgnosta", 10);
}
該示例取自我的博客文章ASP.NET 中的自托管集成測驗。
我經常撰寫這樣的測驗，從邊界開始，然后跟進這樣的單元測驗：
[Fact]
public async Task PostToAbsentRestaurant()
{
var restaurantDB = new InMemoryRestaurantDatabase(Some.Restaurant);
var sut = new ReservationsController(
new SystemClock(),
restaurantDB,
new FakeDatabase());
var absentRestaurantId = 4;
var r = await restaurantDB.GetRestaurant(absentRestaurantId);
Assert.Null(r);
var actual =
await sut.Post(absentRestaurantId, Some.Reservation.ToDto());
Assert.IsAssignableFrom<NotFoundResult>(actual);
}
這個測驗繞過了 HTTP 層，而是針對一個特定的類 ( ReservationsController) - 一個單元測驗。
Nat Pryce 和 Steve Freeman 在他們 2009 年出版的《 Growing Object-Oriented Software, Guided by Tests》一書中很好地描述了這種技術。
轉載請註明出處，本文鏈接：https://www.uj5u.com/caozuo/470391.html