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.

2014-10-11

[Review] 31歲的我 到底幹了什麼好事

31歲的我 到底幹了什麼好事


回顧過去 不僅僅只是留下紀錄
還需要檢討 反省 一年比一年更進步

在事業上

1. 許多的第一次
    (1) 第一次在400人面前 侃侃而談分享出差經驗
    (2) 第一次帶公司的讀書會
    (3) 第一次擔任公司內部講師
    (4) 第一次被徵稿 寫篇文章投到雜誌

2. 推出姓名學的服務
    去年為了取安仔的名字 針對姓名學做了一番研究
    還意外發現 其實可以將這些理論程式化
    於是就在今年四月把核心演算法完成
    推出了姓名學服務
    如何取安安的名字

3. 經營Blog 幾篇技術性的文章
    去年開始重新提筆經營Blog了
    寫Blog 真的是對我幫助很大 舉凡讀書筆記 技術筆記
    需要使用時 馬上去查就能使用  

在家庭上

開始體驗當爸爸的生活了
1. 每天都跟老婆一起幫安仔洗澡 在客廳陪安仔玩樂
    真的是每一天 都是我跟老婆一起幫安仔洗澡
    每一天 洗完澡 都是由我抱著他 去床上擦身體
    每一天 當我回到家之後 就是陪他一直玩一直玩一直玩~
    每一天 到目前為止 安已經快1歲1個月 還是每一天~
 
 
    

2. 以拍照 錄影 寫Blog方式 紀錄安仔一年來的成長
    我愛攝影 所以出遊必帶相機
    去年光幫安仔 應該也拍了上千張的照片
    最後精選300張洗出放到相簿中 約莫15張是用相框方式掛在客廳
 


    除了拍照 錄影也是記錄生活的好物 有些真實的互動相片感覺不出來
    我三不五時就會錄影 並把影片上傳到Youtube
    每次爸媽來 就放出來給他們笑一笑

 

    3.Blog - 以每三個月一次整理安仔的相片與動態
    用Facebook太難整理了 也不好搜尋
    所以決定把安仔的日常系列 放在這個Blog中
    劉栩安的日常生活 - Birth to 3M
    劉栩安的日常生活 - 3M to 6M
    劉栩安的日常生活 - 6M to 9M
    安仔的疝氣手術實記

    4.保險 - 全家的保險都由我一手包辦
       去年幫安仔規劃了雙實支實付配套的不同家保險產品的組合
       想不到今年安仔疝氣手術馬上就用上了
       住單人病房都免擔心~      

在個人生活上

1. 攝影
    自己真的這麼認為 越拍越好了 哈哈
    有抓到老婆與安互動的感覺 所以拍出了幾張感覺不錯的作品
 
親親我的安

就是愛撒嬌

2. 去美國出差 走透透
    去年有這個機會去美國加拿大共6個城市出差 除了公事之外
    在閒暇之餘 也透過大眾交通工具到處趴趴走

    其中最特別的經歷:
     (1) 看NBA - 從San Francisco搭Bart去Oakland勇士隊的主場看比賽
         不得不說 看NBA真的超級high 尤其這場又是42分大逆轉的比賽
         看到後來 都跟身旁不認識的人拍手擊掌 超High
       
   
     (2) 幫求婚 - 在Salt Lake City 摩門教的大本營 Temple Square前方廣場
          有位男子請我幫他跟女友拍照 私底下卻偷偷跟我講 他等下要跟他女友求婚 請我幫他錄影跟拍照 這是我第一次幫人家求婚 我也見證到了女方驚喜的那個瞬間
 

    由於我在美國也都是自己亂亂逛 回來之後總算說服老婆 以後出國自由行就好了

3. 籃球
    去年開始嘗試打控球後衛 由於過去我算是外行人 不太碰控球
    但總覺得我這樣的身高還是得打控球 於是在每個星期的練習
    一有機會還是強迫並推銷自己打控球 一年下來算是進步不少

特別的嘗試

1. 跳舞
    公司春酒表演 自願跑去跳舞 跳舞不是我的專長 但跳完真的很有趣
    原來跳舞真的蠻好玩的

2. 躲避球
    公司內部運動會 擔任躲避球隊隊長 帶領球隊拿下銀牌 重溫小時舊夢
    躲避球真的蠻好玩的呢

反省

1. 前一陣子 不曉得是車騎太快還是睡著了而出了車禍
    也深刻體悟到身為一家之主 自己的重要性
    所以警惕自己 不要騎快車

2. 罵安安
    前三個月真的很難帶 那時我常常顧下半夜 但安仔作息跟我們相反 他白天睡得很好 晚上不怎麼睡 我有時從4點搖搖搖 搖到6點半都還沒睡 然後我就要去上班了 有2,3次我終於理智斷線 大聲罵了他
    事後還很後悔 因為明知道安根本不懂事 罵他只會讓他哭得更慘
    所以EQ還是不夠好 得好好控制磨練

3. 時間管理
    有了小朋友之後 個人的時間真的少了很多很多非常多~
    常常我得等母子倆睡了之後 整理相簿 在facebook貼文
    常常都得2點了才上床睡覺
    其實應該還是有更有效率的方式管理時間