在Web開發中測試單一頁面的功能實在是太麻煩，從首頁使用者名稱、密碼進去後，經過一些操作後才可以來到你要測試的那個頁面。 （其實無論做什麼的開發，測試單一功能都是很麻煩）。抱著小心謹慎的態度，我一般喜歡寫幾段測一次，如果每次都興師動眾的啟動整個計畫來測試顯然是很不經濟的做法。
我通常會在Solution中新增一個用來測試用的配置，在其中增加一個「Test"之類的編譯指令，然後在程式碼中，把一些測試條件，測試方法放到這個指令下。在開發團隊還沒有引進單元測試之類的概念的時候，我可不想用新增一個測試專案這樣的方法來做這種事情。而且對於像Web下單一的Page這樣的情況我也不知道應該是如何進行法。所以還是用以前自己的編譯指令這種方法比較的輕車熟路點。
（我以前在寫一些非WEB下的東西的時候，也喜歡把測試方法與類別本身寫在一個文件裡，然後用編譯指令區分開，如果要測試，就直接在開發環境下選擇"Test"的那個配置，然後啟動TestDriven來測試之，不用啟動整個專案對機器省力多了，TestDriven這個東西很管用的。
如果你是用Ｃ＃作開發的，在開發環境中，如果當前這個編譯條件不滿足的時候，那些程式碼都會灰掉，而且可以縮進，一點都不障眼）
不過我的那些伎倆，在VS2005下有點不管用了，現在WEB開發跟以前有點差別了。在上面找來找去都找不到地方來新增編譯指令，非WEB的開發還是可以找到地方新增的。折騰了半天，發現現在把一些設定的東西都放到Web.config裡面來了，條件編譯當然也不例外。
例如現在要加一個”Test”的條件編譯指令。在Web.config檔中，在
type="Microsoft.VisualBasic.VBCodeProvider, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=B77A5C561934E089" extension=".VbugB= com /define:Trace=True /define:Test=True "/> type="Microsoft.CSharp.CSharpCodeProvider, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=B77A5C561934Eextsion " .cs" compilerOptions="/d:DEBUG;TRACE;Test"/> 很要命的，每一種語言都要加一個 Web.config裡設定過後就不用在每一個需測試的頁面上去定義編譯指令了，不過還是沒有以前爽，以前直接在IDE工具列上選擇一下配置就行了，現在硬是要寫這麼多東西，而且主要還是不方便切換。例如我不要在"Test"條件下啟動時，我還得跑到Web.config裡把上面一段東西註解掉。
根據MSDN的說法，在.Net 2.0下，