很難測試的部分比較常見的有：圖形界面、硬件、數據庫等。下面以圖形界面為例進行說明。
如果一個軟件模塊必須要通過圖形界面才能夠觸發它的應用邏輯時，那么要對這個軟件模塊進行測試時就必須要使用圖形界面。但是圖形界面又是很難測試的�？雌饋砗孟窈茈y辦。讓我們換一個角度考慮一下，其實我們真正想要測試的是軟件模塊本身的應用邏輯，而不是圖形界面的觸發邏輯。如果我們在設計時能夠把被測試的軟件模塊本身進行很好的封裝，定義良好的服務提供接口，那么我們就完全可以通過軟件模塊本身提供的接口進行測試。這樣就可以繞過難以測試的圖形界面。造成上述軟件模塊很難測試的原因正是由于在設計時把軟件模塊本身的應用邏輯和圖形界面這兩個無關的邏輯耦合在了一起。把這兩個邏輯分離，不僅可以對該軟件模塊進行更容易、更有效的測試，而且也使得該軟件模塊具有了很好的可重用性和可移植性。
那么對于不好測試的圖形界面，我們該怎么辦呢？原則很簡單，如果某種東西不好測試，那么就讓它做肯定不會出錯的事情，而把可能會出錯的邏輯剝離出來，放到一個可以測試的模塊中。對于圖形界面來說，就是僅僅保持一個很薄的圖形界面邏輯，它的工作就是把用戶的請求簡單的轉發給真正處理該請求的軟件模塊（一般稱之為Application Facade）。轉發邏輯足夠簡單以至于它肯定不會出錯，所以我們也無需對它進行測試。關于這方面更多的信息，請參見參考文獻[5]。
如果在進行軟件開發時能夠首先編寫測試代碼，那么就會迫使你從易使用性，易測試性的角度開考慮問題，從而你就會專注于軟件模塊的高層抽象和職責。這樣就會定義出清晰的、明確反映意圖的模塊接口來，另外，為了使得測試能夠進行，你就會主動把那些導致不好測試的耦合去掉。這樣的結果不僅僅是獲得了可測試性，并且也產生了更好的設計和系統架構。
?
但是確實存在一些不好測試的東西并且很難只讓它執行一些非常簡單的邏輯，比如嵌入式系統中的BSP（板級支持包）。開發它們所使用的語言、環境以及它們本身的特性等決定了它們是很難測試的。這里說的難測試其實是一個測試代價問題，具體的說就是要付出更多的時間和努力。這就需要你在付出的代價和測試帶來的收益之間進行平衡。如果付出的代價所帶來的收益（更少的調試、維護、發布成本）是巨大的，那么付出的代價就是非常值得的。