对编写的代码进行单元测试
There are probably hundreds of dos and don’ts for writing good code. This list might vary for different languages or frameworks, and some of these guidelines may conflict with each other. In fact, in addition to using these guidelines, developers are often expected to use common sense as well. Design patterns are a classic example of this dilemma; if you start using them blindly without proper understanding and the exact use case then you will soon find that those design patters will turn into anti-patterns.
编写好的代码可能有数百项需要做的事情。 对于不同的语言或框架,此列表可能会有所不同,并且其中一些准则可能会相互冲突。 实际上,除了使用这些准则之外,经常期望开发人员也使用常识。 设计模式是这种困境的经典例子。 如果您在没有正确理解和确切用例的情况下盲目使用它们,那么您很快就会发现这些设计模式将变成反模式。
The same goes for unit test cases. In unit testing, you perform testing on the “smallest” unit or component of your application. Writing unit test cases is not easy, and maintaining them takes additional effort. Every time that you make changes in your component, chances are high that you will either need to add more cases or update already written cases. This article will dive into how to write better code with unit testing.
单元测试用例也是如此。 在单元测试中,您对应用程序的“最小”单元或组件执行测试。 编写单元测试用例并不容易,维护它们需要付出额外的努力。 每次在组件中进行更改时,很有可能需要添加更多案例或更新已编写的案例。 本文将深入探讨如何通过单元测试编写更好的代码。
用例 (Use case)
Let’s consider a case where you are providing a questionnaire to the users. Visually, the questionnaire looks like this:
让我们考虑一下您向用户提供调