正确的单元测试技术 [英] Proper unit testing technique

查看:50
本文介绍了正确的单元测试技术的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

在使用TDD时,我发现自己需要测试一个包含查找值的常量(最终)哈希表(请查看原因,这是为什么情况下处于更新状态)

While Using TDD I found myself needing to test a constant (final) hashmap which contains lookup values (PLEASE SEE REASON WHY THIS WAS THE CASE UNDER UPDATE)

请参见下文

private static final Map<Integer,String> singleDigitLookup = new HashMap<Integer, String>(){{
        put(0,"Zero");put(1,"One");put(2,"Two");put(3,"Three");put(4,"Four");put(5,"Five");put(6,"Six");put(7,"Seven");
        put(8,"Eight");put(9,"Nine");
}}; 

使用TDD时,它必须一次测试一件事,因此我开始调用我的类,以验证每个元素的有效性,如下所示.

With TDD its stressed to test one thing at a time so i started calling my class verifying the validity of each of the elements as below.

测试样式1

TEST STYLE 1

@Test
public void whenWordIsOneThenReturn1(){
   assertEquals(1, WordToIntegerConverter.toInteger("One"));
}

写完第三个测试后,我认为这很荒谬,并使用反向键值对创建了一个临时查找,然后开始循环进行测试,如下所示.

after writing the third test I thought it was pretty ridiculous and created a temporary lookup with the reverse key value pairs and began calling in a loop to test as below.

测试风格2

TEST STYLE 2

@Test
    public void whenWordIsZeroThroughNineReturnIntegerConversion(){
        HashMap<Integer, String> lookup = new HashMap<Integer, String>(){{
            put(0,"Zero");put(1,"One");put(2,"Two");put(3,"Three");put(4,"Four");put(5,"Five");
            put(6,"Six");put(7,"Seven");put(8,"Eight");put(9,"Nine");
        }};
        for(int i = 0; i < 10; i++) {
            assertEquals(i, WordToIntegerConverter.toInteger(lookup.get(i)));
        }
    } 

我的问题是这个;使用样式1进行单元测试更好还是使用样式2更好?

我看到两者的利弊.例如样式1非常简洁,只测试一件事,更容易理解.样式1的缺点除了需要大量键入Test套件外,还会带来许多琐碎的测试.风格2的优点是单元测试较少.样式2的缺点有点复杂,可能要测试一件事以上,但是我认为仅测试一件事就可以证明常量哈希图的有效性.

I see pros and cons for both. for example style 1 is very concise, test only one thing and easier to understand. cons for style 1 besides doing a ton of typing the Test suite will blow up with many trivial test. Pros for style 2 is less unit tests. cons for style 2 has a bit of complexity and may be testing more than one thing but I would argue its only testing one thing the validity of the constant hashmap.

更新 我从这个问题中得到了很大的反响,所以让我进一步解释.它不是我本身关心的常量,而是验证我的代码的不同情况.这是一个练习问题(通过Katas练习TDD),而不是生产代码.问题在于将数字转换为单词,因此我在单元测试中关心的是确保我可以正确处理不同的可能数字.还有其他一些我没有包含的常量,例如常量存储青少年数字(11,12,13 ...)和tensDigits(20,30,40 ...).在这里打错字相当容易.

UPDATE I've received a decent amount of blowback from this question so let me further explain. Its not the constant I care about per se but validating the different cases of my code. This Was a practice problem (Practicing TDD Via Katas) not production code. The problem was converting numbers to words so what I care about in my unit testing is ensuring I could properly handle the different possible numbers. There were other constants that I didn't include for example constant storing teen numbers (11, 12, 13...) and tensDigits(20, 30, 40...). Its fairly easy to make a typo here.

推荐答案

方法1完成工作,只是需要大量的剪切粘贴.方法2可以解决此问题,但要以测试不是独立的为代价:如果一项测试失败,则不会运行以下测试.修复一个测试只是为了发现一堆新的测试现在失败了,这很烦人.您可以通过进行参数化测试来对此进行改进,这是来自junit Wiki的示例:

Approach #1 gets the job done, just with an obnoxious amount of cut-n-pasting. Approach #2 fixes that, but at the expense that the tests aren't independent: if one test fails the following ones don't run. Fixing one test just to find a bunch of new ones now fail is pretty annoying. You can improve on this by making a parameterized test, here's an example from junit's wiki:

@RunWith(Parameterized.class)
public class FibonacciTest {
    @Parameters
    public static Collection<Object[]> data() {
        return Arrays.asList(new Object[][] {     
                 { 0, 0 }, { 1, 1 }, { 2, 1 }, { 3, 2 }, { 4, 3 }, { 5, 5 }, { 6, 8 }  
           });
    }

    private int fInput;

    private int fExpected;

    public FibonacciTest(int input, int expected) {
        fInput= input;
        fExpected= expected;
    }

    @Test
    public void test() {
        assertEquals(fExpected, Fibonacci.compute(fInput));
    }
}

参数化测试包括输入/​​期望输出对的集合,对于每对输入和输出,将其传递到测试的构造函数调用中,并在新的测试实例上调用test方法.循环保留在测试框架中,并保留在测试之外,并且每个测试成功或失败都与其他测试无关.

The parameterized test includes a collection of input/expected-output pairs, for each pair the input and output get passed into the constructor call for the test and the test method is called on the new test instance. The looping is kept in the test framework and out of the test, and each test succeeds or fails independently of the others.

这篇关于正确的单元测试技术的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆