主持人注意： 這里已經發(fā)布了39個答案（有些已經刪除）。 你發(fā)布之前你的答案，考慮你是否能添加一些有意義的討論。您很有可能只是重復別人已經說過的話。我偶爾會發(fā)現(xiàn)自己需要在類中公開一個私有方法，只是為此編寫了一些單元測試。通常這是因為該方法包含該類中其他方法之間共享的邏輯，并且更愿意自己測試該邏輯，或者還有另一個原因是我想測試同步線程中使用的邏輯而不必擔心線程問題。其他人是否發(fā)現(xiàn)自己正在這樣做，因為我真的不喜歡這樣做？我個人認為，好處超過了公開方法的問題，而該方法實際上并沒有在課堂之外提供任何服務...更新謝謝大家的回答，似乎引起了人們的興趣。我認為，普遍的共識是應該通過公共API進行測試，因為這是使用類的唯一方法，我對此表示同意。我在上面提到的我在上面會做的幾個案例是不常見的案例，我認為這樣做的好處是值得的。但是，我可以看到每個人都指出，它永遠不會真正發(fā)生。而且，當我多考慮一下時，我認為更改代碼以容納測試是一個壞主意-畢竟，我認為測試在某種程度上是一種支持工具，并且如果可以的話，將系統(tǒng)更改為“支持支持工具”是公然的壞習慣。
3 回答
哆啦的時光機
TA貢獻1779條經驗 獲得超6個贊
注意：
此答案最初是針對以下問題而發(fā)布的：單獨進行單元測試是否是通過getter公開私有實例變量的充分理由？它已合并到此示例中，因此可能是針對此處顯示的用例的一點點。
一般而言，我通常都會重構“生產”代碼以使其更易于測試。但是，我認為這不是一個好電話。一個好的單元測試（通常）通常不必關心類的實現(xiàn)細節(jié)，而只關心其可見行為。不必將內部堆棧暴露給測試，而是可以測試該類在調用first()或之后以您期望的順序返回頁面last()。
例如，考慮以下偽代碼：
public class NavigationTest {
private Navigation nav;
@Before
public void setUp() {
// Set up nav so the order is page1->page2->page3 and
// we've moved back to page2
nav = ...;
}
@Test
public void testFirst() {
nav.first();
assertEquals("page1", nav.getPage());
nav.next();
assertEquals("page2", nav.getPage());
nav.next();
assertEquals("page3", nav.getPage());
}
@Test
public void testLast() {
nav.last();
assertEquals("page3", nav.getPage());
nav.previous();
assertEquals("page2", nav.getPage());
nav.previous();
assertEquals("page1", nav.getPage());
}
}
冉冉說
TA貢獻1877條經驗 獲得超1個贊
就個人而言，我寧愿使用公共API進行單元測試，并且我絕對不會公開私有方法只是為了使其易于測試。
如果您真的想單獨測試私有方法，則可以在Java中使用Easymock / Powermock來執(zhí)行此操作。
您必須對此務實，并且還應該知道難以測試的原因。
' 聽測試 '-如果很難測試，是否告訴您有關您的設計的一些信息？您能否將這種方法的測試重構到可以通過公共api進行測試的地方并輕松覆蓋？
這就是邁克爾·費瑟斯（Michael Feathers）在“ 有效地使用舊版代碼 ”中所說的話
“許多人花費大量時間試圖解決該問題……真正的答案是，如果您有測試專用方法的沖動，則該方法不應該是專用的；如果將該方法公開，麻煩您了，可能是因為它是單獨職責的一部分；它應該在另一個類上?！?[ 有效地使用舊法典（M. Feathers，2005年）]
添加回答
舉報
0/150
提交
取消