国内大型免费网站建设,济宁万达网站建设,建手机端网站,商城网站建设市场分析论文vue 脚手架测试环境莱昂#xff1a;Luc Besson的专业人士 当我开始通过创建相同的对象并准备用于运行测试的数据来重复进行单元测试方法时#xff0c;我对设计感到失望。 带有大量代码重复的长测试方法看起来并不正确。 为了简化和缩短它们#xff0c;基本上有两个选择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 wordsgamma.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 IterableFile 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 wordsgamma.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.htmlvue 脚手架测试环境
