2014-10-23

[讀書筆記] The art of Unit Testing - ch2 - A first unit test

[讀書筆記] A first unit test

2.1 Frameworks for unit testing

Doing things completely manually would be error-prone and time-consuming, and people would defer doing that as much as possible.

手動出錯的機會很大 又浪費時間
所以請讓Unit-testing framework來協助你寫測試吧

2.1.1 What unit-testing frameworks offer

所以unit-testing framework到底你提供你什麼服務呢?
先想想目前手寫的測試(沒用framework)有怎樣的缺點
  • They were not structured. (

每次測試你可能都是用不同介面來測試 ex. Webform, Winform or WinConsole)

  • They were not repeatable. (無法執行過去的測試)
  • They were not on all your code. (沒有測到所有的code 如果寫UT是很方便的 RD才會盡可能地多寫UT 增加Coverage)
Unit-testing Framework能幫助你解決上述問題

Framework的介入是獨立的 你能在你的TestProject寫完Test Case 再透過統一的介面去執行測試
以下列出了Framework導入後對RD的協助:
1. Write tests easily and in a structured manner.
    Framework都已經定義好結構跟使用方法
    所以寫UT時 只要繼承或是follow API 就能寫出UT
    非常方便且結構化
2. Execute one or all of the unit tests.
    透過GUI或是command 執行所有的tests
    重點是能夠自動化
3. Review the results of the test runs.
    跑完test之後的Report 能夠一目瞭然問題出在哪裡?

2.1.2 The xUnit frameworks

C++ : CppUnit / (GoogleTest)
JAVA : JUnit
.NET : NUnit

2.3 First steps with NUnit

2.3.1 Installing Nunit

先去Nunit官網下載最新的Nunit並安裝
http://www.nunit.org


2.3.2 Loading up the solution

打開NUnit GUI 之後 選擇Open Project 就能將你寫的Test Project 載入 
注意!! 這裡載的是Test Project 不是ProductionCode Project



接下來就能開始執行NUnit了

2.3.3 Nunit attributes

寫UT之前 先來了解NUnit 有哪些attribute可以用
Naming
在寫UT時 最好也follow建議的naming style (潛規則)
Project : 
Create a test project named [ProjectUnderTest].Tests. 

Class : 
For each class, create at least one class with the name [ClassName]Tests.

Method : 
For each method, create at least one test method with the following name: 
[MethodName]_[StateUnderTest]_[ExpectedBehavior]

MethodName : The name of the method you’re testing
StateUnderTest : The conditions used to produce the expected behavior (這個method要執行的動作)

ExpectedBehavior : What you expect the tested method to do under the specified conditions (預期的測試Return Value)

For example:
有個Method叫做 IsValidLogFileName, 這個method的目的是要驗證filename是否合法, 接下來我們要寫一個UT去測這個method, 預期結果為True

所以UT的method name 應該為 :
IsValidFileName_validFile_ReturnsTrue


2.4 Writing our first test

1. Add Reference
    要在Test Project 使用到NUnit必須先using NUnit.Framework
    注意!! 不是加在Production Code    

2. [TestFixture]
    請在每個Test Class上方加上[TestFixture]
    
3. [Test]
    請在每個Test Method上方加上[Test]
    注意!! NUnit的test method都必須為 void 且不帶任何parameters
     ex. public void IsValidFileName_validFile_ReturnsTrue(){...}

4. Arrange, Act, and Assert
    每個Test Method內都需要包含這三個內容:    
  •     Arrange objects, creating and setting them up as necessary.   
  •     Act on an object.  
  •     Assert that something is as expected.
For example:

Create出一些資源 設一些設定
呼叫Production code中待測的這支method
透過Assert 比對結果是否符合自己預期

Assert有很多條件跟API能呼叫
請到官網Document查詢
目前我採用的是NUnit 2.6.3版 
http://www.nunit.org/index.php?p=assertions&r=2.6.3

以下就先列AreEqual跟AreSame的不同點
Assert.AreEqual
這個是值比對
Assert.AreSame
這個是Reference比對

Writing UT Process




2.5 More Nunit attributes

2.5.1 SetUp and TearDown

For unit tests, it’s important that any leftover data or instances from previous tests are destroyed and that the state for the new test is recreated as if no tests have been run before.

一個很重要的原則:
每個測試都像是新的一樣 不要殘留之前的data

所以我們需要SetUp跟TearDown的觀念

[SetUp]

This attribute can be put on a method, just like a [Test] attribute, and it causes NUnit to run that setup method each time it runs any of the tests in your class.



每次執行[Test]之前 就會執行[SetUp]
你可以把[SetUp]想成Constructors

[TearDown]
This attribute denotes a method to be executed once after each test in your class has executed.

每次執行[Test]完之後 就會執行[TearDown]
你可以把[SetUp]想成Destructors

[SetUp]跟[TearDown]是每次執行[Test]都會執行的
那有沒有類似的概念是 for Class [TestFixture]的?

[TestFixtureSetUp]
執行[TestFixtureSetUp] Before all [Test]

[TestFixtureTearDown]
執行[TestFixtureTearDown] After all [Test]

[TestFixtureSetUp]或[TestFixtureTearDown]的用途是當資源setting up 或 cleaning up花太久時 只想執行一次時使用

如下圖:

2.5.2 Checking for expected exceptions

  • The expected exception message is provided as a parameter to the [ExpectedException] attribute.
  • There’s no Assert call in the test itself. The [ExpectedException] attribute contains the assert within it.
  • There’s no point getting the value of the Boolean result from the method because the method call is supposed to trigger an exception.

有時候我們會預期什麼情況下會丟出Exception
此時就能用[ExpectedException]來測試是否有丟出相關Exception

預期要測Exception 就不用Assert (其實已經含在[ExpectedException]中)

For example:

2.5.3 Ignore tests

Sometimes you’ll have tests that are broken and you still need to check in your code to the main source tree.

有時候你不想要Fail的Test中斷你的其他test 可以善用[Ignore]
設定[Ignore]之後 Test就能忽略掉這個TestMethod
在NUnit GUI 看到的顏色就會變成黃色

For example:


如果Ignore內寫了"內容" 
[Ignore("XXX")]
就會在GUI中的Test Property中顯示Reason="XXX"

2.5.4 Setting test categories

我們也能夠透過[Category("A")]將Test分組
如此可透過NUnit測試特定Category

For example:

2.6 Indirect testing of state

State-based testing
State-based testing (also called state verification) determines whether the exercised method worked correctly by examining the state of the system under test and its collaborators (dependencies) after the method is exercised.

有時候狀態的測試不是直接的
如同下列情況

有個Class Calculator 他有
兩個Method :
public void Add(int number);
public int Sum();
一個Property:
private int sum=0;

每次呼叫Add 累加完之後的值會存在sum中

Add return void 這樣我們該如何驗證Add呢?
Solution:
要切兩個Test Case
1. Default Sum應該要為0
2. 呼叫Add之後 Sum應該要正確

注意!! Add_CalledOnce_SavesNumberForSum()
因為這個測試主要還是測試Add的邏輯
所以最好還是以Add來命名

如下圖:

2.7 Summary

作者希望大家記住下面四點:

  • It’s common practice to have one test class per tested class, one test project per tested project, and at least one test method per tested method.
  • Name your tests clearly using the following model: [MethodUnderTest]_[Scenario]_[ExpectedBehavior].
  • Use the [SetUp] and [TearDown] attributes to reuse code in your tests, such as code for creating and initializing objects all your tests use.
  • Don’t use [SetUp] and [TearDown] to initialize or destroy objects that aren’t shared throughout the test class in all the tests, because it makes the tests less understandable. Someone reading your code won’t know which tests use the logic inside the setup method and which don’t.

一個Project就對應一個TestProject
一個Class就對應一個TestClass
一個Method至少要對應一個TestMethod

Follow [MethodUnderTest]_[Scenario]_[ExpectedBehavior] 規則

善用[SetUp]及[TearDown]對資源操作
相反地也不要在這兩處放置非所有Test用到的資源

2014-10-22

[讀書筆記] The art of Unit Testing - ch1 - The basics of unit testing

[讀書筆記] The basics of unit testing

1.1 Unit Testing - the classic definition

What is the classic definition?
A unit test is a piece of a code (usually a method) that invokes another piece of code and checks the correctness of some assumptions afterward.
If the assumptions turn out to be wrong, the unit test has failed. 
A "unit" is a method or function.

傳統的Unit Test就是寫另外的code去check你的production code是否正確
一個Unit就是以一個method或function為單位

傳統上大部份公司的現況:
1. Rely on System and Integration Test
    倚靠Integration Test來測
2. Manually testing
    手測
3. Test by using the end product
    利用UI來測

其實我們或多或少都一定寫過測試
如下圖:

我們可能會寫個WinForm或是WebForm透過UI呼叫我們寫的code來驗證正確性

實際上這樣的測試離Good Unit Test 還有一大段距離


1.2 Properties of a good unit test

所以到底Good Unit Test有什麼樣的特性呢?

  • It should be automated and repeatable.
  • It should be easy to implement.
  • Once it’s written, it should remain for future use.
  • Anyone should be able to run it.
  • It should run at the push of a button.
  • It should run quickly.
  • 要能夠自動化
  • 要容易實作
  • 一旦寫好未來都能使用
  • 每個人都能執行它
  • 按個button就能執行
  • 要能夠快速地執行


各位可以問問自己以下的問題:

  • Can I run and get results from a unit test I wrote two weeks or months or years ago?
  • Can any member of my team run and get the results from unit tests I wrote two months ago?
  • Can I run all the unit tests I’ve written in no more than a few minutes?
  • Can I run all the unit tests I’ve written at the push of a button?
  • Can I write a basic unit test in no more than a few minutes?


問問自己 如果有任何一題的答案是no
那麼你寫的test 可能就不屬於Unit Test


1.3 Integration tests

What is the Integration Test?

Integration testing means testing two or more dependent software modules as a group.

Integration test 就是把兩個以上的modules組合起來一起測試

If the test fails, all the parts fail together; if it succeeds, the parts all succeed.

所以Integration Test 面臨的問題是
If the test fails, all of these software components fail as a team, and it can be difficult to figure out what caused the failure of the overall operation.

因為要死就一起死 很難抓出root cause
如下圖:



Integration Test的問題就在於有很多的Failure points你必須一一排除

1.3.1 Drawbacks of integration tests compared to automated unit tests

讓我們回想剛剛自問的問題:
Can I run and get results from a unit test I wrote two weeks or months or years ago?
A: code change是相當常見的 在改完code之後 是否知道有side effect? 所以需要Unit Testing !!!

作者將此稱為 "accidental bugging"

Regression
A regression is a feature that used to work and now doesn’t.
過去可以work 現在不行

Good tests should be easily executed in their original form, not manually.

Can any member of my team run and get the results from unit tests I wrote two months ago?
A:如同第一題 只是這是改別人的code
    大部分人都會擔心Legacy code
    因為會怕改Legacy code又造成side effect

Legacy code
Legacy code is defined by Wikipedia as “source code that relates to a no-longer supported or manufactured operating system or other computer technology,” but many shops refer to any older version of the application currently under maintenance as legacy code. It often refers to code that’s hard to work with, hard to test, and usually even hard to read.

Good tests can be accessed and run by anyone.

Can I run all the unit tests I’ve written in no more than a few minutes?
A:如果test需要很久 那麼你也就不會很常去測試了
    這邊講的是 便利性

Good tests should run quickly.

Can I run all the unit tests I’ve written at the push of a button?
A:如果不行 那代表你必須經過重重難關才能測試(ex.設定 or 雜事) 如果不方便 那麼你也不想去測試了
    這邊講的是 便利性

Good tests should be easily executed in their original form, not manually.


Can I write a basic unit test in no more than a few minutes?
A:測試的scope越大 牽扯的module越多 測試就越難寫
    如果測試越難寫 那麼你也不想去測試了
    這邊講的是 便利性

其實這段也偷偷暗示我們應該要使用Unit-Testing Framework來寫測試才會方便

Good tests against the system should be easy and quick to write.


1.4 Good Unit Test

引言至此 作者終於要帶出他心目中 Good Unit Test的定義了

  • A unit test is an automated piece of code that invokes the method or class being tested and then checks some assumptions about the logical behavior of that method or class.
  • A unit test is almost always written using a unit-testing framework.
  • It can be written easily and runs quickly.
  • It’s fully automated, trustworthy, readable, and maintainable.
好的Unit Testing就是 使用unit-testing framework 自動化地去測logical behavior
必須很方便的實作測試 執行測試也必須很快看到結果

Logical code
Logical code is any piece of code that has some sort of logic in it, small as it may be.

It’s logical code if it has one or more of the following: an IF statement, a loopswitch or case statements, calculations, or any other type of decision-making code.

只有logical code需要測試

反例:
像Java的 get/set 如果沒有內含邏輯的話 其實不用測它


1.5 A simple unit test example

這個章節 作者寫了一個測試範例 但他並沒有使用Unit-testing framework
我們可以看看就算沒有Unit-testing framework 測試的邏輯還是一樣 但是就是麻煩了些 所以有framework的協助 會讓各位更方便地寫Unit Test 才會讓大家有動力去寫


1.6 Test-driven development

大部分的人是在實作完production code之後才開始寫測試
但作者相當推薦先寫測試再寫code
這種方式就稱之為TDD 

傳統的coding process如下圖:
TDD的coding process如下圖:
TDD的流程如下:

1 Write a failing test to prove code or functionality is missing from the end product.
    先寫測試 所以沒有production code的結果就是FAIL

2 Make the test pass by writing production code that meets the expectations of your test.
    接下來我們應該要想辦法讓Test PASS

3 Refactor your code.
    經過幾個Test Pass之後 或許開始發現可以refactor一些code
    此時就能放心地refactoring

Refactoring
Refactoring means changing a piece of code without changing its functionality.
If you’ve ever renamed a method, you’ve done refactoring.
If you’ve ever split a large method into multiple smaller method calls, you’ve refactored your code.
The code still does the same thing, but it becomes easier to maintain, read, debug, and change.

這邊其實帶出一個Unit-testing的優勢就在於我們能夠放心地refactoring 因為改壞馬上就被Unit Test抓出來


1.7 Summary

作者不斷的想強調 什麼是Good Unit Test
因為很重要 所以要一直重複提
What is a good unit testing?
  • It’s an automated piece of code that invokes a different method and then checks some assumptions on the logical behavior of that method or class.
  • It’s written using a unit-testing framework.
  • It can be written easily.
  • It runs quickly.
  • It can be executed repeatedly by anyone on the development team.