有人爲pojos做過測試嗎？

0

Pojos仍然可能包含邏輯錯誤。

來源

2008-09-18 02:58:42 Nescio

0

如果沒有經過測試，它有一個錯誤！ ;）

來源

2008-09-18 02:59:13 Aaron

+0

如果它已經過測試，它可能仍然有一個錯誤。測試驅動的方法非常適用於消除明顯的錯誤和迴歸，但它會發現找不到預期的錯誤。把它看成是一件擦亮劑。你做多少拋光是一個偏好問題。 – 64BitBob 2008-09-18 04:07:56

+0

您的陳述和我的陳述可以同時爲真。 – Aaron 2008-09-18 12:51:19

0

當然這是必要的。所有必須工作的代碼都必須經過測試。

來源

2008-09-18 02:59:56 Allen

0

當然，你還會做什麼測試用例？

我喜歡做Test Driven Development，它很多關於測試你的pojos（呃，其實它關於設計你的pojos）。

來源

2008-09-18 03:00:04 Gilligan

0

通常情況下。如果你的模型沒有按預期工作，你將會遇到很多麻煩......

在光明的一面，測試它們會容易得多。

來源

2008-09-18 03:00:46 Swati

2

如果您的PoJos包含對您的業務非常重要的邏輯，那麼當然，測試它們。

如果他們不這樣做，那麼不要打擾。有時候在沒有測試的情況下離開課程很重要，因爲它可以讓您自由地在以後重構它。

來源

2008-09-18 03:06:09 kbaribeau

6

我爲除了簡單的getter和setter之外的所有東西都寫了明確的測試。

如果getter或setter只包含return blah;或this.blah = blah;我認爲沒有太大的價值。大部分時間都是這些產生的，我覺得將測試結合在一起的時間可以更好地花在其他地方。

來源

2008-09-18 03:07:57 RichH

1

我的確除了吸氣和吸氣。你必須在某處畫線。

來源

2008-09-18 03:47:03

0

當然，如果它們包含「任務關鍵」代碼，您將需要測試它們。

來源

2008-09-18 03:51:22

2

很容易說「當然」。但是，這是爲什麼：在真正的軟件中，你有層層組件。很容易地說，在堆棧底部的小小的pojos太小而不能有真正的錯誤，但是當你在軟件中遇到意想不到的結果，並且將所有涉及未經徹底測試的代碼相加時，整個Jenga一堆嫌疑人。但是，如果您在構建高級功能之前測試較低級別的例程，那麼當出現問題時，您就知道應該在哪裏查看（即，在低級別例程上重新運行測試之後，確保某些東西沒有改變）。

還要記住，爲您的pojos編寫測試應該相對容易，因爲模塊提供的功能越少，測試的功能就越少。

我同意不測試getter和setters。

來源

2008-09-18 04:05:04

1

POJO通常在某些情況下進行測試。如果你想執行一些邏輯，必須正確測試（理想情況下在開始邏輯實現之前）。至於吸血鬼和二傳手;測試它們通常不是必需的，因爲覆蓋率是通過測試邏輯來獲得的:-)嘗試檢查一些覆蓋率報告工具，如Cobertura，Clover或嘗試Emma，看看需要測試什麼。我真的很喜歡Clover報告，顯示代碼中最危險的威脅。

來源

2008-09-18 05:18:37

4

我認爲這個問題對術語有些困惑。 POJO（普通Java對象）指的是一個Java對象，它不依賴於特定應用程序服務器或第三方庫的依賴關係。使用像Spring這樣的良好的IOC（Inversion Of Control）框架，可以將所有的類編寫爲POJO，這樣您就可以獨立測試它們，而無需在測試中啓動應用服務器。

Java bean是一個簡單的Java類，它包含私有屬性和公共getBlah（）和setBlah（）存取方法，而沒有其他很多。 Java bean本質上是POJO。

所以如果問題是「我應該測試我的POJO（包含業務邏輯）嗎？」答案是強調是的。

如果問題是「我應該測試我的Java bean（它們是沒有行爲的簡單值對象）嗎？」答案可能不是。

來源

2008-09-18 06:24:13

-1

不，我不考的POJO因爲：

1.-如果POJO包含buseness邏輯，我從POJO提取出來，當然，我測試了。但是那個測試已經不在POJO中。

2.-如果POJO不包含它，即simple/getters/setters方法，我在構建時或運行時動態生成它（CGLIB）。所以我測試我的代碼生成器，但不是我的POJO。

來源

2008-09-18 07:20:41

1

因此，正如其他人在此提到的那樣，是的，您需要測試它們。但是，如果您是通過TDD設計需求創建它們的，那麼一旦您運行代碼覆蓋率工具，就會發現這些POJO（或POCO對於我們.net窺視）實際上將被覆蓋。這是因爲TDD只允許你編寫/重構由某些單元測試驅動的代碼。

這使得TDD比單元測試更好，恕我直言。

來源

2008-09-18 13:56:26 casademora

1

那麼，還有另一個維度，人們似乎被省略了。

是的，當你想到POJO時，只有任何人的想法是相應的getter和setter屬性。但是，除此之外，POJO還可以在重寫的equals（）和hashCode（）方法的幫助下同樣貢獻於Collections中。 :)在這種情況下，我的POJO值得進行體面測試！ :)

您應該使用不同的可能值測試不同的時間，並確保equals（）和hashCode（）組合不會提供重複值！

來源

2010-11-21 07:12:31

0

你需要做的，即使是「純」的getter和setter這些原因：

代碼覆蓋 - 如果你使用了CC的工具，那麼你會想增加你的覆蓋面
一些在未來的時間有人可能會決定把一些邏輯在你的getter和setter方法之一，那麼你的測試可能會失敗讓下發展調整測試（提高警覺性）

將是不錯的自動有一個工具生成這些測試雖然...

來源

2016-03-04 08:44:59 ACV

有人爲pojos做過測試嗎？

回答

相關問題