vue 腳手架測試環(huán)境

萊昂：Luc Besson的專業(yè)人士

當(dāng)我開始通過創(chuàng)建相同的對象并準(zhǔn)備用于運行測試的數(shù)據(jù)來重復(fù)進(jìn)行單元測試方法時，我對設(shè)計感到失望。 帶有大量代碼重復(fù)的長測試方法看起來并不正確。 為了簡化和縮短它們，基本上有兩個選擇，至少在Java中：1）通過@Before和@BeforeClass初始化的私有屬性，以及2）私有靜態(tài)方法。 他們倆對我來說都是反面向?qū)ο蟮?#xff0c;我認(rèn)為還有另一種選擇。 讓我解釋。

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());} }

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

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

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

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

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;} }

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

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

盡管比以前的設(shè)計要好得多，但這種設(shè)計的主要問題是它不能防止測試“類”之間的代碼重復(fù)。 如果在另一個測試用例中需要類似Folder類型的測試治具，則必須將該靜態(tài)方法移到那里。 甚至更糟的是，我將不得不創(chuàng)建一個實用程序類。 是的，在面向?qū)ο蟮木幊讨袥]有什么比實用程序類更糟糕的了。

更好的設(shè)計是使用“偽”對象而不是私有靜態(tài)實用程序。 這是怎么回事。 首先，我們創(chuàng)建一個偽造的類并將其放入src/main/java 。 必要時，此類可用于測試以及生產(chǎn)代碼中（ 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);} }

這是我們的測試現(xiàn)在的外觀：

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提供的更好嗎？ 它不是比實用程序方法更具可重用性和可擴(kuò)展性嗎？

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

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

vue 腳手架測試環(huán)境

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。