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:

让我们考虑一下您向用户提供调查表的情况。 从视觉上看，调查表如下所示：

These are the features of this component:

这些是此组件的功能：

1. Display query/question
   显示查询/问题
2. Options from which a user may choose to select one or more options
   用户可以选择从中选择一个或多个选项的选项
3. A “skip for now” option if the user is not interested in responding to any particular prompt
   如果用户对响应任何特定提示不感兴趣，则为“立即跳过”选项

We’ll call this component the Multi-select component. Now you may decide to turn this entire component into a single file, or you may want to break it into multiple small units. The above component can be broken into:

我们将此组件称为Multi-select组件。 现在，您可以决定将整个组件转换为一个文件，或者将其拆分为多个小单元。 上面的组件可以分为：

• A question section

  问题部分

• An options section

  选项部分

• A skip section

  跳过部分

Can we further split these units into smaller units (and more importantly is this even necessary)? While the Question and Skip sections seem to be small enough since they have a single concern each, the Options section still has multiple concerns.

我们能否将这些单元进一步拆分成较小的单元(更重要的是，这甚至是必要的)吗？ 尽管“问题”和“跳过”部分似乎足够小，因为它们每个都有一个关注点，而“选项”部分仍然有多个关注点。

细分选项部分 (Breaking down the options section)

Right now this component has two concerns:

目前，此组件有两个问题：

1. Render the list of options
   呈现选项列表
2. Handle the selection of each of these options
   处理每个选项的选择

We can break the component into smaller units by separating out or delegating the concern to independent components. So the smaller units that can be created by breaking the options section would be:

通过将关注点分离或委托给独立的组件，我们可以将组件分解为较小的单元。 因此，可以通过打破选项部分创建的较小单位为：

• Option componentThis is concerned with rendering an actual component and providing API that supports selection/de-selection of option as well as showing the current state of the component

  选项组件这涉及到渲染实际组件并提供支持选项的选择/取消选择以及显示组件当前状态的API。

• OptionList componentThis renders the list of options only. Invoking an Option component for each option that needs to be displayed to the user and provides the relevant data/functions needed for the option component

  OptionList组件这仅呈现选项列表。 为每个需要显示给用户的选项调用一个选项组件，并提供该选项组件所需的相关数据/功能

You may be wondering why we need to break the options section down further and perhaps deem this unnecessary. One of the answers to this question is “unit testing”.

您可能想知道为什么我们需要进一步细分选项部分，也许认为这是不必要的。 这个问题的答案之一是“单元测试”。

If you were to perform unit testing for the options section then you won’t be able to test certain behavior which will be private to the component; for example, the selection of an option. Changing the API of your components to support unit testing is an anti-pattern and is not recommended. Whereas — by breaking the options section into an option and optionlist — we have a component that provides API on an option level.

如果要对选项部分执行单元测试，则将无法测试组件专有的某些行为。 例如，选择一个选项。 更改组件的API以支持单元测试是一种反模式，因此不建议这样做。 而通过将选项部分分为一个选项和一个选项列表，我们有了一个在选项级别提供API的组件。

结论 (Conclusion)

Writing unit test cases is not always possible and it's not a one-off task. If you write unit test cases you also need to maintain them; depending on how much tech bandwidth you have and what your priorities are as a team and organization.

编写单元测试用例并不总是可能的，而且不是一项一次性的任务。 如果编写单元测试用例，则还需要维护它们。 取决于您拥有多少技术带宽以及团队和组织的工作重点。

Even if you don’t have time to write test cases, or have not yet started writing them, if you consider the case “what if I have to write test case?” while deciding the architecture of your application/feature (and especially at the implementation phase) it’ll help you in breaking your code into smaller units which are prerequisites for effective unit test cases.

即使您没有时间编写测试用例，或者尚未开始编写测试用例，如果您认为用例“我必须编写测试用例怎么办？” 在确定应用程序/功能的体系结构(尤其是在实现阶段)时，它将帮助您将代码分成较小的单元，这是有效的单元测试用例的前提。