今日因為想組織下 d source code, 所以 download 左 Regionerate 黎用
之前 VS 2002 都有用過類似 Sort Code 既 Macro, 但我見 VS 2008 用果時有問題 (sort 完走位, 係唔啱既地方 cut 左我 d code), 所以就搵過第二個.
今次呢個都 ok, group 都所有 method, variable, constructor 同 properties, 不過行完後 d encode 好似有 d 問題, 要成日自己選返個 encode method.
類似既野聽講 Resharper 都做到, 但可惜, 要錢已經係一個問題.
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 而重做半小時既測試結果既慘況下, 自動化測試變成我寫軟件生活既其中一個有興趣深入研究既地方.
Exception – 從來都被初哥覺得係個麻煩既來源, 但其實佢只係一個提醒工具, 話比大家知那裡有問題.
好多課程, 以及書本都有教點處理 Exception, 但如何正確使用 Exception 就好似得 Pragmatic Programmer 一書內有提及.
通常我使用 Exception 既地方會有以下幾個, 作用係提醒返 d 唔正常既動作, 因為唔 throw 既話, 使用者 (包括自己) 都會唔知或者唔記得:
1. Design By Contract
主要用 Exception 黎 validate 所有 input 或 pre-condition, 令佢有個 Valid State 比佢 perform action
public void Cancel()
{
if (item.IsLoaning)
throw new InvalidOperationException("Please return the loan before cancel");
}
2. Supporting of Share Module
public static IDbDataAdapter CreateDbDataAdapter(IDbCommand command)
{
IDbDataAdapter adapter = null;
if (command is SqlCommand)
{
adapter = new SqlDataAdapter((SqlCommand)command);
}
if (command is OleDbCommand)
{
adapter = new OleDbDataAdapter((OleDbCommand)command);
}
if (command is OdbcCommand)
{
adapter = new OdbcDataAdapter((OdbcCommand)command);
}
if (adapter != null)
{
return adapter;
}
throw new NotSupportedException();
}
3. Supporting on different framework
public void NewFeature()
{
#if !USING_NEW_FRAMEWORK
throw new NotSupportedException();
#else
doSomething();
#endif
}
4. 又或者係未做完的工作, 不過好多時都會寫 // TODO
public void DoSomething()
{
throw new NotImplementedException();
}
用左 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;
}
