Javascript 编写描述性单元测试

我正在尝试用Python编写单元测试，并努力找到一种描述性的方法来做事情。我有JavaScript背景，我使用

mocha

，这有助于我进行描述性描述

这就是我所说的“描述性”的意思：

foo.js

exports.foo = function (type, isLogged, iOk) {
    if (type === undefined) throw new Error('a cannot be undefined');
    if (isLogged === undefined) throw new Error('b cannot be undefined');
    if (isLogged) {
        if (type === 'WRITER') {
            return isOk ? "writer" : -1;
        } else {
            return "something else"
        }
    }
}

describe('#foo()', function () {
    context('when type is undefined', function () {
      ...
    })
    context('when isLogged is undefined', function () {
      ...
    })
    context('when type is defined', function () {
        context('when isLogger is not defined', function () {
         ...
        })
        context('when isLogged is defined', function () {
            context('when type is not WRITER', function () {
             ...
            })
            context('when type is WRITER', function () {
                context('when isOk is true', function () {
                 ...
                })
            })
        }) 
    })
})

foo.spec.js

exports.foo = function (type, isLogged, iOk) {
    if (type === undefined) throw new Error('a cannot be undefined');
    if (isLogged === undefined) throw new Error('b cannot be undefined');
    if (isLogged) {
        if (type === 'WRITER') {
            return isOk ? "writer" : -1;
        } else {
            return "something else"
        }
    }
}

describe('#foo()', function () {
    context('when type is undefined', function () {
      ...
    })
    context('when isLogged is undefined', function () {
      ...
    })
    context('when type is defined', function () {
        context('when isLogger is not defined', function () {
         ...
        })
        context('when isLogged is defined', function () {
            context('when type is not WRITER', function () {
             ...
            })
            context('when type is WRITER', function () {
                context('when isOk is true', function () {
                 ...
                })
            })
        }) 
    })
})

当我用Python编写单元测试时，我最终得到了如下结果：

foo.spec.py

class TestFoo:
    def test_when_type_is_undefined(self):
        ...
    def test_when_isLogged_is_undefined(self):
        ...
    # This test name is too long
    def test_when_type_is_defined_and_isLogged_is_undefined_and_type_is_writer_when_is_ok_is_true(self):
        ...

---

如何以更好的方式组织这些测试？关于描述性单元测试的最佳实践是什么？有好的单元测试的好例子吗？

我认为您的单元测试构造没有任何问题。单元测试应该非常具有描述性，因此一旦测试失败，问题就显而易见了。作为一个信息很少的开发人员，testcase

test\u when\u type\u是定义的，when\u isLogged\u是未定义的，when\u是确定的，when\u type\u是编写的，when\u是真的，testcase
告诉了我很多关于哪里出了问题以及在哪里查找的信息

通过在
assert
语句中添加一条错误消息，您可以使测试更具描述性，这样当某项操作失败时，您就可以确切地知道原因。例如：“期望writer
ok
，但writer没有”

对我来说，测试所在文件的名称、测试用例的名称和断言消息应该给出代码失败的原因和原因的清晰路径。
您可以在代码中使用类似BDD的语法

例子：
输出
当然，拥有有意义的测试方法名称很重要，但是，当测试名称变得非常长且不可读时，您总是可以在方法内部提供完整的测试描述

以下是一些：

请注意，您可以在控制台上看到这些文档字符串，并增加了
的详细程度。演示：

虽然我基本上同意您的意见，但如果我尝试遵守PEP8，则方法名称不能超过100个字符。如何做到这两个？我几乎虔诚地遵循PEP8。然而，这是一项任务，而不是一项授权。如果您的代码更有意义，并且以这种方式对您来说更具可读性，那么这是您的最佳方式！
def test_cookielib_cookiejar_on_redirect(self, httpbin):
    """Tests resolve_redirect doesn't fail when merging cookies
    with non-RequestsCookieJar cookiejar.
    See GH #3579
    """
    cj = cookiejar_from_dict({'foo': 'bar'}, cookielib.CookieJar())
    s = requests.Session()
    # ...

def test_headers_on_session_with_None_are_not_sent(self, httpbin):
    """Do not send headers in Session.headers with None values."""
    ses = requests.Session()
    ses.headers['Accept-Encoding'] = None
    # ...

$ cat test_module.py
import unittest


class BasicTestSuite(unittest.TestCase):
    def test_one(self):
        self.assertEqual(1, 1)

    def test_two(self):
        """Extended description"""
        self.assertEqual(2, 2)

if __name__ == '__main__':
    unittest.main()

$ python -m unittest -v test_module
test_one (test_module.BasicTestSuite) ... ok
test_two (test_module.BasicTestSuite)
Extended description ... ok

----------------------------------------------------------------------
Ran 2 tests in 0.000s

OK