浙江省住房建设厅继续教育网站,重庆百度推广排名,建个淘宝那样的网站需要多少钱,网站开发手机端junit 预期错误有时#xff0c;当我们收到对jOOQ或其他库的拉取请求时#xff0c;人们会将单元测试中的代码更改为更“惯用的JUnit”。 特别是#xff0c;这意味着他们倾向于更改此代码#xff08;公认的不是那么漂亮的代码#xff09;#xff1a; Test
public void tes… junit 预期错误 有时当我们收到对jOOQ或其他库的拉取请求时人们会将单元测试中的代码更改为更“惯用的JUnit”。 特别是这意味着他们倾向于更改此代码公认的不是那么漂亮的代码 Test
public void testValueOfIntInvalid() {try {ubyte((UByte.MIN_VALUE) - 1);fail();}catch (NumberFormatException e) {}try {ubyte((UByte.MAX_VALUE) 1);fail();}catch (NumberFormatException e) {}
} …成为“更好”和“更清洁”的版本 Test(expected NumberFormatException.class)
public void testValueOfShortInvalidCase1() {ubyte((short) ((UByte.MIN_VALUE) - 1));
}Test(expected NumberFormatException.class)
public void testValueOfShortInvalidCase2() {ubyte((short) ((UByte.MAX_VALUE) 1));
}我们获得了什么 没有 当然我们已经必须使用Test批注因此我们不妨使用其expected的属性吧 我声称这是完全错误的。 有两个原因。 当我说“两个”时我的意思是“四个” 1.在代码行数方面我们并没有真正获得任何好处 比较语义上有趣的位 // This:
try {ubyte((UByte.MIN_VALUE) - 1);fail(Reason for failing);
}
catch (NumberFormatException e) {}// Vs this:
Test(expected NumberFormatException.class)
public void reasonForFailing() {ubyte((short) ((UByte.MAX_VALUE) 1));
} 给定或采用空格格式基本语义信息量完全相同 该方法正在测试中的ubyte() 。 这不会改变 我们要传递给失败报告的消息以字符串或方法名称的形式 异常类型和预期的事实 因此即使从样式角度来看这也不是真正有意义的更改。 2.无论如何我们都必须将其重构 在注释驱动的方法中我所能做的就是测试异常类型 。 例如在以后要添加更多测试的情况下我无法对异常消息做出任何假设。 考虑一下 // This:
try {ubyte((UByte.MIN_VALUE) - 1);fail(Reason for failing);
}
catch (NumberFormatException e) {assertEquals(some message, e.getMessage());assertNull(e.getCause());...
} 3.单一方法调用不是单位 单元测试称为testValueOfIntInvalid() 。 因此 通常在输入无效的情况下要测试的语义“单位”是UByte类型的valueOf()行为的语义“单位”。 不适用于单个值例如UByte.MIN_VALUE - 1 。 不应将其拆分为更小的单元仅仅是因为这是我们可以将Test注释刺入其功能范围的唯一方法。 TDD伙计们请听听。 我从不希望将我的API设计或我的逻辑塞进由“向后”测试框架不是个人的JUnit强加的一些怪异的限制。 永不 “我的” API比“您的”测试重要100倍。 这包括我不想 公开一切 使一切都没有定论 使一切都可以注射 使所有内容均为非静态 使用注释。 我讨厌注解。 不。 你错了。 Java已经不是一种太复杂的语言但是让我至少可以使用我想要的任何方式使用它提供的一些功能。 不要因为测试而在我的代码上强加您的设计或语义上的毁损。 好。 我React过度了。 我总是在带有批注的情况下 。 因为… 4.对于控制流结构而言注释始终是错误的选择 一次又一次我为Java生态系统中的注释滥用而感到惊讶。 注释对于三件事有好处 可处理的文档例如Deprecated 方法成员类型等的自定义“修饰符”例如Override 面向方面的编程例如Transactional 并且要注意 Transactional是使其成为主流的少数几个真正有用的方面之一日志挂钩是另一个方面或者如果绝对必须的话可以进行依赖注入。 在大多数情况下AOP是解决问题的利基技术您通常在普通程序中不希望这样做。 用注解对控制流结构进行建模绝对不是一个好主意更不用说测试行为了 是。 Java已经采用了很长的缓慢的方法来包含更复杂的编程习惯。 但是如果您对单元测试中偶尔的try { .. } catch { .. }语句的冗长内容感到不满那么您可以找到解决方案。 是Java 8。 如何用Java 8更好地做 JUnit lambda正在开发中 http : //junit.org/junit-lambda.html 他们将新的功能性API添加到新的Assertions类中 https : //github.com/junit-team/junit-lambda/blob/master/junit5-api/src/main/java/org/junit/gen5/api /Assertions.java 一切都基于Executable功能接口 FunctionalInterface
public interface Executable {void execute() throws Exception;
} 该可执行文件现在可以用于实现断言引发或不引发异常的代码。 请参见Assertions的以下方法 public static void assertThrows(Class? extends Throwable expected, Executable executable) {expectThrows(expected, executable);
}public static T extends Throwable T expectThrows(ClassT expectedType, Executable executable) {try {executable.execute();}catch (Throwable actualException) {if (expectedType.isInstance(actualException)) {return (T) actualException;}else {String message Assertions.format(expectedType.getName(), actualException.getClass().getName(),unexpected exception type thrown;);throw new AssertionFailedError(message, actualException);}}throw new AssertionFailedError(String.format(Expected %s to be thrown, but nothing was thrown., expectedType.getName()));
} 而已 现在那些反对try { .. } catch { .. }块的冗长的人可以重写此代码 try {ubyte((UByte.MIN_VALUE) - 1);fail(Reason for failing);
}
catch (NumberFormatException e) {} …进入 expectThrows(NumberFormatException.class, () - ubyte((UByte.MIN_VALUE) - 1)); 如果我想对异常进行进一步检查可以这样做 Exception e expectThrows(NumberFormatException.class, () - ubyte((UByte.MIN_VALUE) - 1));
assertEquals(abc, e.getMessage());
... 出色的工作JUnit lambda团队 函数式编程每次都会击败注释 注释被滥用了很多逻辑 主要是在JavaEE和Spring环境中它们都非常渴望将XML配置移回Java代码。 这是错误的方法这里提供的示例清楚地表明与使用批注相比几乎总是有一种更好的方法可以使用面向对象或功能编程来显式地写出控制流逻辑。 在Test(expected ...)的情况下我得出结论 安息 expected 无论如何它不再是JUnit 5 Test批注的一部分 翻译自: https://www.javacodegeeks.com/2016/01/use-junits-expected-exceptions-sparingly.htmljunit 预期错误
