不單元測試意味着測試必須嘲笑或單元測試的定義可以是不嘲笑?單元測試是否意味着測試必須被模擬?
例如下面,此試驗是嘲笑,所以它是單元測試:下面
/**
* @test
*/
public function it_should_return_true_if_ssh_client_is_connected()
{
$this->phpSecLibShh->shouldReceive('isConnected')->andReturn(true)->once();
$this->assertTrue($this->shell->connected($this->phpSecLibShh));
}
實施例,是這樣的單元測試或集成測試?我不清楚這個:
/**
* @test
*/
public function it_should_get_half_price_discount()
{
$cost = 50;
$order = new Order();
// It does not connect to database or any other service
$discounted = $order->discount(Order::DISCOUNT_HALF_PRICE, $cost);
$this->assertEquals(25, $discounted);
}
不按照Martin Fowler的(https://martinfowler.com/bliki/UnitTest.html)... [單元測試的定義,對於他(和Kent Beck,JUnit和TDD的創造者),在單元測試被測試的單元不一定必須與其依賴關係隔離。就個人而言,我認爲孤立的單元測試通常是一個壞主意,應該避免。 –
@Rogério我很欣賞你的評論。單元測試是我們運行了很多次的東西。如果我們更改事件一行代碼,我們可以運行單元測試,以確保更改不會影響到目前爲止編寫的任何功能邏輯。現在認爲,在您的業務邏輯中,您正在調用外部付費Web服務的業務邏輯。如果你不嘲笑那項服務,那麼你每次運行單元測試都會付錢。我同意測試應該被隔離,但它也應該與依賴隔離。隔離意味着一個代碼單元。 –
當然,如Fowler的文章中提到的那樣,當調用「笨拙的合作者(如遠程信用卡驗證系統)」時,確實有意義進行模擬。但是,這種情況應該是例外而不是常態,而且在大多數現實世界的代碼庫中都非常罕見。嘲笑圖書館的問題是沒有經驗的開發人員往往會濫用它們(以及濫用它們,因爲它們固有的複雜性)。我從開發一個嘲笑圖書館12年的經驗中瞭解到這一點,同時支持用戶,並看到他們經常犯的錯誤。 –