I'm CaLendarW Blog

Test Driven Development, 係以測試來驅動程式既設計, 目的係為了提高軟件既質素.

好多人覺得測試對軟件方面只在於用戶接受測試 (UAT), 因為只要通過 UAT, 公司就可以袋袋平安. 不過, UAT 通常都浪費人手, 而且該次 UAT 只計對於該次既軟件需求, 當需求需要更改, 所有既測試都要人手重頭做過, 浪費人力物力.

自動化軟件測試既好處係可以減省人手及時間, 以及提高軟件既質素及完整度.

以下係一個由 NUnit 提供既自動化測試例子:

// 一個 object oriented 既 Account class
namespace bank
{
  public class Account
  {
    private float balance;
    public void Deposit(float amount)
    {
      balance+=amount;
    }

    public void Withdraw(float amount)
    {
      balance-=amount;
    }

    public void TransferFunds(Account destination, float amount)
    {
    }

    public float Balance
    {
      get{ return balance;}
    }
  }
}

namespace bank
{
  using NUnit.Framework;

  [TestFixture]
  public class AccountTest
  {
    // 自動化測試來測試 TransferFunds Method
    [Test]
    public void TransferFunds()
    {
      Account source = new Account();
      source.Deposit(200.00F);
      Account destination = new Account();
      destination.Deposit(150.00F);

      source.TransferFunds(destination, 100.00F);
      Assert.AreEqual(250.00F, destination.Balance);
      Assert.AreEqual(100.00F, source.Balance);
    }
  }
}

以上只係其中一個例子用來測試軟件既完成度, 在現實上, Test Case 除左要測驗一般情況外, 仲要測試錯誤情況出來既結果, 保証軟件質素, 所以正常使用既情況係唔會得一個 Test Case 咁少.

要實行 Test Driven Development, 通常要有一個良好既 Object Oriented Design 以及 Design for Test, 如果沒有這兩個設計既技巧, 那測試既質素有可能會受影響.

愈多 Test Case 未必代表軟件的準確率愈高, 正常情況 Test Case 既數量應該多過 Use Case 既數量, 而且會因應不同既考慮點而增加一定的測試數量, 以我所知, 在某些大學既科目中, 有計算要有多少 Test Case 既試題 (因為我都有睇過), 用作驗證是否足夠全面地測試每一行代碼.

在測試失敗時, 有問題既地方除了可能係軟件本身外, 自動化測試部份亦有可能會有錯誤, 錯誤既多少在乎實現 Test Case 既人對軟件測試既知識同經驗所得.

雖然軟件在有測試既環境下推出, 但有時都有可能會在軟件發現有 bug 既情況, 當遇到這個情況下, Programmer / Tester 應該用 Test Case 去模擬問題既環境, 當得出相同既結果後才可以更改軟件, 因為未能模擬出相同環境下更改軟件, 失敗後亦未知是軟件問題定 Test Case 問題, 所以 Programmer 應該先更改 Test Case 後才更改軟件, 而更改軟件途中, Programmer 亦可透過測試來避免 side effect 出現, 所以不段發現問題環境才能提高軟件既完整性, 以及提高軟件人員對軟件既信心.

測試, 除了要滿足軟件既完整性, 亦要滿足不段改變既需求, 世界變, 軟件同測試不變就只會不進則退, 所以為新既需求而更改軟件及擴充其功能既環境下, 自動化測試係必須的.

一年前我工作既地方, 因為無自動化測試, 軟件無 Design for Test, 要用到硬件 及 3rd Party 提供既模擬程式下, 人手測試既時間應該超過一個月, 除了測試一個月既時間外, 測試既人手通常都要兩至三人, 而且大部份都係重複既輸入工作, 以及已改幾句 code 而重做半小時既測試結果既慘況下, 自動化測試變成我寫軟件生活既其中一個有興趣深入研究既地方.

用左 VS 2008 其實都幾個月, 但因公司目標係 .net 2.0 既關係, 技術始終都仲停留緊係 2.0 度, 近日開始習慣緊 C# 3.0 既 syntax, 有幾個新 feature 係 2.0 platform 都幾好用.

Object initializers
呢個係一個新既 contractor syntax, 可以好方便咁創建同設定 Value. 但如果個 Properties 係 private set; 既話就用唔到啦!!

Customer c1 = new Customer { Name="James" };
Customer c2 = new Customer { Name="Tom" };

Lambda expressions
Lambda 好好用!! 簡單, 快捷!!

string name = "James";
IList<Customer> result = list.FindAll(x => name.Equals(x.Name));

Automatic properties
呢個可以簡化到部份 properties, 但如果有 business logic 既話就唔係太啱用

public decimal UnitPrice
{
    get;
    private set;
}

近半年開始著重地寫 Windows Application (以前以 web 同 DLL 為主), 寫左咁耐都無用過 Control.Dock 呢個屬性, 今日第一次用, 就出左好多次序上既問題, 不過在網上找到以下既解決方案, 當解決了次序既問題後, Dock 其實係幾好用!!~~

private void RemoveBtn(Button btn1)
{
	if(this.Controls.Contains(btn1))
		this.Controls.Remove(btn1);
}

private void SetDockProperity(Button btn1, DockStyle dockStyle)
{
	btn1.Dock = dockStyle;
}

private void DockTop_Click(object sender, System.EventArgs e)
{
	RemoveBtn(this.button1);
	RemoveBtn(this.button2);
	RemoveBtn(this.button3);
	SetDockProperity(this.button1, System.Windows.Forms.DockStyle.Top);
	SetDockProperity(this.button2, System.Windows.Forms.DockStyle.Top);
	SetDockProperity(this.button3, System.Windows.Forms.DockStyle.Top);
	this.Controls.Add(this.button3); // 注意順序, 後 Add 的最上面
	this.Controls.Add(this.button2);
	this.Controls.Add(this.button1);
}

private void DockBottom_Click(object sender, System.EventArgs e)
{
	RemoveBtn(this.button1);
	RemoveBtn(this.button2);
	RemoveBtn(this.button3);
	SetDockProperity(this.button1, System.Windows.Forms.DockStyle.Bottom);
	SetDockProperity(this.button2, System.Windows.Forms.DockStyle.Bottom);
	SetDockProperity(this.button3, System.Windows.Forms.DockStyle.Bottom);
	this.Controls.Add(this.button3);  // 注意順序, 後 Add 的最下面
	this.Controls.Add(this.button2);
	this.Controls.Add(this.button1);
}

轉載自: 藍色小鋪

Visual Studio .NET C# Add-In by DevExpress Available Free of Charge
Support Visual Studio 2008 but I haven’t it yet.

15 Useful Project Management Tools
Start to use trac now!! for myself.

An Overview of C# 4.0
It’s too freedom…… and not good for beginner!!

平時寫介面(GUI), 通常會寫一個 method 叫 StateChange 黎處理所有介面上既所有 visible 同 enable 既動作. 而自己會因介面既設計而定義一個 private enum 既 State, 所有 state 由一個 method 做晒.

private enum State
{
    Add,
    Update
}

private void StateChange(State eState)
{
    if (eState == State .Add)
    {
        txtId.Visible = true;
        lblId.Visible = false;
        lblMode.Text = "[Add New]";
    }

    if (eState == State .Update)
    {
        txtId.Visible = false;
        lblId.Visible = true;
        lblMode.Text = "[Update]";
    }
}

而我自己寫過既 State 都有幾隻:
同一版有個所有 Item 既 List 而 Edit box 得 Add 同 Update

private enum State
{
    Add,
    Update
}

一版得主要係用黎 Insert 既:

private enum State
{
    WaitingSave,
    WaitingConfirm    // for double confirm
}

同埋得睇同改既:

private enum State
{
    Normal,
    Edit    // for add and update
}

仲有好多其他既 State 寫過, 不過都太過多同太專門, 所以應該係按照實際用途而加.

網上曾經見過有人用 State object 同 State Pattern 黎做, 對我而言好似用係 GUI 方面未必真係有咁既需要, 但對一個 domain object 而言就最好有 State object, 咁樣會對個 design 好好多.