數日前China-Pub和我連絡，希望我為China-Pub寫些賀詞做為7周年之慶，霎時間我不禁喃喃自語的對自己說已經7年了嗎? 回想上次去China-Pub拜訪才彷彿是不久之前的事情，時間怎麼過的這麼快。China-Pub的成功是有目共睹的，也恭喜China-Pub 7年有成之慶。我知道的許多作者也都為China-Pub寫了恭賀之詞，真是熱鬧，有興趣的朋友可以到下面的URL參觀。

http://www.china-pub.com/STATIC07/0707/zh_zuozhe_070716.asp

回到數年前使用C++或是Delphi開發有關資料庫應用程式的時光，我已經記不住花了多少次的時間在建立測試資料庫，測試資料等不斷重覆的工作來測試和處理資料相關的程式碼。更由於以前在做專案時不同的專案會使用不同的資料庫，而這些資料庫又通常是由系統分析師或是DBA管理，因此不但資料庫綱要(Database Schema)是由系統分析師/DBA來建立和管理，經常開發人員需要使用的測試資料表，測試資料可能又不被系統分析師/DBA所重視或是系統分析師/DBA不瞭解開發人員需要的測試資料(雖然我看過許多的開發人員似乎對於資料測試沒有花費太多的時間)。更麻煩的情形是有時系統分析師/DBA改變了資料庫綱要但是開發人員並不知情，這讓許多應用程式失去正確性而開發人員卻渾然不知，最後的結果當然就是開發人員被K的滿頭包了。這就像10幾年前我還是菜烏級開發人員一樣，想想那時被系統分析師/DBA狠狠修理的情形到現在嘴角還不禁浮出苦笑。

前一陣子研究Ruby On Rails(當然是因為CodeGear很快就要推出ROR的IDE的原因)，發覺ROR有非常棒的測試功能，除了支援單元測試，功能測試和整合測試之外，更棒的是ROR還提供了非常好用的資料測試能力。在ROR中開發人員可以結合單元測試和資料測試來測試資料庫中的資料是否正確，也提供自動在資料表中預先產生測試資料的能力，更可以在測試資料中撰寫Ruby程式碼來產生動態的測試資料，這實在是太cool了，為什麼以前沒有類似的東西呢，因為這太好用了，特別是結合結合單元測試和資料測試應該是每一個資料庫開發人員都需要使用到的。

不過我很貪心想要的更多，其實這是因為我以前身受其苦，那就是如果系統分析師/DBA更改了資料庫綱要之後，開發人員也能夠測試並且據此找出可能會受影響的應用程式? 另外由於專案可能會使用不同的資料庫，那麼如果修改了資料庫綱要之後從一個資料庫，例如Oracle，轉換到另外的資料庫，例如InterBase，那麼由於不同的資料庫使用的資料型態不同，開發完成的資料庫應用程式又如何確保仍然能夠正確的執行?

因此如果我們能夠擁有上述的所有解決方案那該多好。

對於Delphi/C++來說，由於Delphi/C++不是稿本語言(script language)，因此無法像Ruby一樣在應用程式執行時再解釋(Interpret)文件之中包含的程式碼，因此ROR可以在文件中內嵌Ruby程式碼來動態產生測試資料。例如ROR可以藉由Fixtures把下面YAML文件中的測試資料自動產生在測試資料表中:

dave:

  id:   1

  name: dave

  salt: NaC1

  hashed_password: ksahfd#@$@%^$%^#FSDF

ROR也可以使用動態Fixtures功能在YAML檔案中包含Ruby程式碼呼叫我們寫好的Ruby程式碼來動態產生測試資料:

dave:

  id:   1

  name: dave

  salt: <%= SALT %>

  hashed_password: <%= User.encrypted_password('secret', SALT) %>

這樣的功能很cool，但是對於Delphi/C++這等靜態程式語言卻很難做到。不過如果Delphi/C++藉由XUnit系列卻可以模擬類似的效果並且提供更多好用的功能。這是什麼意思? 讓我們從比較技術的角度來討論一下。

在DUnit中有測試案例的類別TTestCase，因此如果我們從TTestCase擴充新資料庫測試類別:

TDBTestCase = class(TTestCase)

…

end;

接著我們可以複載SetUp和TearDown方法開啟資料庫的連結以及關閉資料庫連結:

TDBTestCase = class(TTestCase)

  protected

    procedure SetUp; override;

    procedure TearDown; override;

…

end;

再接著我們可以定義一些方法來測試，例如定義TestDataGenerator來測試自動產生的資料，CheckAgainstGenerator來測試資料表綱要和資料是否正確:

TDBTestCase = class(TTestCase)

  protected

    procedure SetUp; override;

    procedure TearDown; override;

…

    procedure CheckAgainstGenerator(欄位資訊，自動資料產生器);

    procedure TestDataGenerator;

end;

如此一來如果分析師/DBA更改了資料庫綱要，那麼只要我們反覆執行TDBTestCase就可以測試每一個資料表的綱要(CheckAgainstGenerator)。有趣的是上面的自動資料產生器可以定義成一個類別來根據資料表綱要自動產生需要的測試資料。例如:

  TDataGenerator = class

  …

  end;

當然要能夠測試資料表綱要以及自動產生的測試資料，我們需要非常強大的MetaData類別，這個新的MetaData類別必須能夠讓開發人員使用Delphi/C++程式碼來建立各種資料庫物件，新的MetaData類別能夠把這些程式碼自動轉換為DDL，例如下面的程式碼:

var

  MetaDataTable: TDBXMetaDataTable;

  Command: TDBXCommand;

  Row: Integer;

begin

  MetaDataTable := TDBXMetaDataTable.Create;

  MetaDataTable.TableName := 'QCXXX_TABLE';

  MetaDataTable.AddColumn(TDBXInt32Column.Create('C1'));

  MetaDataTable.AddColumn(TDBXDecimalColumn.Create('C2', 10, 2));

  MetaDataTable.AddColumn(TDBXUnicodeCharColumn.Create('C3', 32));

  MetaDataProvider.CreateTable(MetaDataTable);

最後為了應付各種不同的資料庫，我們可以為不同的不同的定義不同的映射類別。例如:

  TDatabaseDialect = class

…

那麼我們就可以衍生出各種資料庫的子類別，例如:

  TInterbase_2007Dialect = class(TBaseDialect)

  public

    constructor Create; override;

  end;

  TMSSQL_2005Dialect = class(TBaseDialect)

  public

    constructor Create; override;

  end;

最後我們當然就可以為我們的資料庫測試工作建立一個測試案例套件了:

  TDatabaseSuite = class(TTestSuite)

  private

    FDialect: TDialect;      //used for each test

    class function MethodsToTest(ADialect: TBaseDialect; AClass: TDBTestCase Class): TDBXCTSTests;

  protected

    procedure SetUp; override;

    procedure TearDown; override;

  public

    constructor Create(ADialect: TDialectClass; TestClass: TDBTestCase Class  ); overload;

  end;

這個測試案例套件接受特定的資料庫映射類別，再測試所有的資料測試類別。

有了這些類別之後，因此在ROR中自動產生資料的工作就可以由TDataGenerator類別來代替，各種資料測試的工作就可以由TDBTestCase類別來執行。如果再結合MetaData類別，那麼開發人員可以完成通用的資料測試工作，適用在各種不同的資料庫，不同的資料庫綱要，自動產生測試資料，自動建立資料表，刪除資料表，建立MetaData，刪除MetaData，這將擁有無數的資料測試工作可以藉由這些類別來自動的完成，這將多美妙啊。也許我們甚至可以結合Delphi程式語言即將提供的泛型功能進一步的延伸這些強大，方便的功能，甚至整合到Delphi/BCB的IDE中。如果您有開發任何和資料庫相關的應用程式，那麼想想您每天下班之前讓電腦自動執行所有您的資料庫測試案例，那麼我相信您每天一定睡得更安穩，或是能夠節省更多的時間打魔獸爭霸III(Grin).

我現在真的希望10幾年前就有這些好東西。

昨天博文的朋友告訴我Delphi MDA/DDA程序設計-使用ECO一書的庫存已經是零了，這也代表這本書的銷售相當不錯，已經超過了我和出版社當初的估計。身為作者的我當然需要謝謝所有支持本書的朋友，讓這本深入而小眾的技術書籍能夠在幾乎3個月左右的時間完成它的任務，也讓我吃了一個定心丸，一本用心撰寫的技術書籍仍然會被市場所接受。

隨著ECO IV即將現身而且可以和.NET上的AJAX框架一起使用，讓我個人更期待ECO未來的發展，此外ECO R&D團隊也表示可能會推出VS.NET的版本，這也意謂ECO將會讓更多的開發人員所接觸，瞭解和使用。

我個人是希望Delphi MDA/DDA程序設計-使用ECO一書能夠有機會推出新版本，加入ECO IV新功能以及和AJAX框架合作使用的內容。最後再次謝謝所有支持本書的讀者。

昨天我才收到內部的Email說Delphi For PHP Update 2開始進行測試，沒想到今天一早就在CodeGear的Blog網站(blogs.codegear.com)上看到CodeGear在公開徵求Delphi For PHP Update 2的Beta測試人員。由於Delphi For PHP發行之後在全世界的反應都不錯，Delphi For PHP應該算是CodeGear獨立出來之後第一款自行發表的產品，因此CodeGear對於這個產品的反應也非常快速。我目前在Delphi For PHP Update 2中看到了許多朋友反應給我的臭蟲都在Update 2的修復計劃之中，更重要的是Update 2也將強化VCL For PHP的文件，這對於使用Delphi For PHP的朋友而言應該是非常好的訊息，當然Delphi For PHP Update 2也代表CodeGear對於Delphi For PHP客戶的服務承諾，就我個人而言真的很高興看到CodeGear迴異於Borland的精神。

對於Delphi For PHP Update 2有興趣的朋友可以參考下面URL的內容:

http://blogs.codegear.com/ChrisPattinson/archive/2007/07/11/37197.aspx

今天我在CodeGear的網站中終於看到了關於ECO未來發展的重要訊息，那就是ECO R&D團隊已經獨立成為新公司: CapableObjects。CapableObjects公司的新首頁是在: http://www.capableobjects.com/

有興趣的網友可以在下面的URL閱讀全文:

http://dn.codegear.com/article/36723

在http://dn.codegear.com/article/36723中說明了為什麼ECO R&D團隊決定獨立成為新公司，其中一個Q&A點出了ECO的計劃(或是野心)，那就是ECO準備也發表ECO FOR VS.NET，因此未來ECO將同時支援BDS(CDS)和VS.NET。我相信這個訊息對於ECO有興趣的朋友或是正使用ECO的開發人員是非常令人高興的事情，因為這代表ECO將以整個.NET的發展的重心而不只是存在於一個單一的IDE。

目前最新版的ECO IV正開始於Highlander中進行Beta測試，我也快等不及試用ECO IV，特別是在最近大量接觸RoR之後，對於ECO也更有興趣。ECO IV承諾了許多重要的功能，又特別在執行效率方面準備大幅的加強，這就更令人期待ECO IV了。

如果未來有任何ECO IV最新的訊息我也將不時的更新各位。

原本上星期5我有一場次的C++Builder 2007線上研討會, 由於InterWise的伺服器發生問題，因此導致上星期5下午3點開始的線上研討會無法進行，在此向所有上星期5欲參加的朋友道歉，我們會再找適當的時間舉行，謝謝。