vue 腳手架測試環境

萊昂：Luc Besson的專業人士

當我開始通過創建相同的對象并準備用于運行測試的數據來重復進行單元測試方法時，我對設計感到失望。 帶有大量代碼重復的長測試方法看起來并不正確。 為了簡化和縮短它們，基本上有兩個選擇，至少在Java中：1）通過@Before和@BeforeClass初始化的私有屬性，以及2）私有靜態方法。 他們倆對我來說都是反面向對象的，我認為還有另一種選擇。 讓我解釋。

JUnit正式建議一個測試裝置 ：

public final class MetricsTest {private File temp;private Folder folder;@Beforepublic void prepare() {this.temp = Files.createTempDirectory("test");this.folder = new DiscFolder(this.temp);this.folder.save("first.txt", "Hello, world!");this.folder.save("second.txt", "Goodbye!");}@Afterpublic void clean() {FileUtils.deleteDirectory(this.temp);}@Testpublic void calculatesTotalSize() {assertEquals(22, new Metrics(this.folder).size());}@Testpublic void countsWordsInFiles() {assertEquals(4, new Metrics(this.folder).wc());} }

我認為該測試正在做什么很明顯。 首先，在prepare() ，它創建Folder類型的“測試裝置”。 在所有三個測試中將其用作Metrics構造函數的參數。 這里要測試的實際類是Metrics而this.folder是我們測試它所需要的。

此測試有什么問題？ 有一個嚴重的問題：測試方法之間的耦合 。 測試方法（以及所有常規測試）必須彼此完全隔離。 這意味著更改一項測試不得影響任何其他測試。 在此示例中，情況并非如此。 當我想更改countsWords()測試時，必須更改before()的內部，這會影響測試“類”中的其他方法。

在充分尊重JUnit的情況下，在@Before和@After中創建測試裝置的想法是錯誤的，主要是因為它鼓勵開發人員耦合測試方法。

這是我們可以改善測試并隔離測試方法的方法：

public final class MetricsTest {@Testpublic void calculatesTotalSize() {final File dir = Files.createTempDirectory("test-1");final Folder folder = MetricsTest.folder(dir,"first.txt:Hello, world!","second.txt:Goodbye!");try {assertEquals(22, new Metrics(folder).size());} finally {FileUtils.deleteDirectory(dir);}}@Testpublic void countsWordsInFiles() {final File dir = Files.createTempDirectory("test-2");final Folder folder = MetricsTest.folder(dir,"alpha.txt:Three words here","beta.txt:two words""gamma.txt:one!");try {assertEquals(6, new Metrics(folder).wc());} finally {FileUtils.deleteDirectory(dir);}}private static Folder folder(File dir, String... parts) {Folder folder = new DiscFolder(dir);for (final String part : parts) {final String[] pair = part.split(":", 2);this.folder.save(pair[0], pair[1]);}return folder;} }

現在看起來好點了嗎？ 我們還沒有，但現在我們的測試方法已完全隔離。 如果要更改其中一個，則不會影響其他參數，因為我將所有配置參數都傳遞給私有靜態實用程序（！）方法folder() 。

一種實用方法，對嗎？ 是的， 聞起來 。

盡管比以前的設計要好得多，但這種設計的主要問題是它不能防止測試“類”之間的代碼重復。 如果在另一個測試用例中需要類似Folder類型的測試治具，則必須將該靜態方法移到那里。 甚至更糟的是，我將不得不創建一個實用程序類。 是的，在面向對象的編程中沒有什么比實用程序類更糟糕的了。

更好的設計是使用“偽”對象而不是私有靜態實用程序。 這是怎么回事。 首先，我們創建一個偽造的類并將其放入src/main/java 。 必要時，此類可用于測試以及生產代碼中（ Fk表示“偽造”）：

public final class FkFolder implements Folder, Closeable {private final File dir;private final String[] parts;public FkFolder(String... prts) {this(Files.createTempDirectory("test-1"), parts);}public FkFolder(File file, String... prts) {this.dir = file;this.parts = parts;}@Overridepublic Iterable<File> files() {final Folder folder = new DiscFolder(this.dir);for (final String part : this.parts) {final String[] pair = part.split(":", 2);folder.save(pair[0], pair[1]);}return folder.files();}@Overridepublic void close() {FileUtils.deleteDirectory(this.dir);} }

這是我們的測試現在的外觀：

public final class MetricsTest {@Testpublic void calculatesTotalSize() {final String[] parts = {"first.txt:Hello, world!","second.txt:Goodbye!"};try (final Folder folder = new FkFolder(parts)) {assertEquals(22, new Metrics(folder).size());}}@Testpublic void countsWordsInFiles() {final String[] parts = {"alpha.txt:Three words here","beta.txt:two words""gamma.txt:one!"};try (final Folder folder = new FkFolder(parts)) {assertEquals(6, new Metrics(folder).wc());}} }

你怎么看？ 它不是比JUnit提供的更好嗎？ 它不是比實用程序方法更具可重用性和可擴展性嗎？

總而言之，我認為單元測試中的腳手架必須通過與生產代碼一起提供的偽造對象來完成。

翻譯自: https://www.javacodegeeks.com/2015/05/a-few-thoughts-on-unit-test-scaffolding.html

vue 腳手架測試環境

總結

以上是生活随笔為你收集整理的vue 脚手架测试环境_关于单元测试脚手架的几点思考的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。