vue 脚手架测试环境_关于单元测试脚手架的几点思考

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提供的更好吗？它不是比实用程序方法更具可重用性和可扩展性吗？

总而言之，我认为单元测试中的脚手架必须通过与生产代码一起提供的伪造对象来完成。