前述
这是vue.js设计模式的第三章的3.3节代码放在开头，可以先折叠起来，需要的是再打开查看
问题前述:我们已经通过提取函数的方式，将validator将对象字面量中提取了出来成为一个独立函数validateVariant。这带来的好处就是测试的时候可以单独测试这个函数。使我们的测试代码更健壮和可维护。见以下代码
js
<script>
export function validateVariant(variant) {
if (!['success', 'warning', 'error'].includes(variant)) {
throw Error(
`variant is required and must` +
`be either 'success', 'warning' or 'error'.` +
`You passed: ${variant}`
)
}
return true
}
export default {
props: {
variant: {
type: String,
required: true,
validator: validateVariant
}
}
}
</script>
js
import { render, screen } from '@testing-library/vue'
import Message, { validateVariant } from './message.vue'
describe('Message', () => {
it('renders variant correctly when passed', () => {
// omitted for brevity ...
})
it('validates valid variant prop', () => {
;['success', 'warning', 'error'].forEach(variant => {
expect(() => validateVariant(variant)).not.toThrow()
})
})
it('throws error for invalid variant prop', () => {
expect(() => validateVariant('invalid')).toThrow()
})
})关键概念：关注点分离
在测试中，我们有针对UI的测试，通常测试中带有classList等页面元素的判断；也有针对业务逻辑的测试，比如props中的validator，当开发一个组件的时候，这个验证校验接收符合业务的值并通过，不通过则发送一个警告或者错误(见上述)。
为了让问题更清晰，想象你的公司专注于设计系统，而你有着一些使用Figma或Sketch的设计师，设计了一些button和信息这样的组件。他们决定了组件要支持三个表示不同信息的变量:success，warning 和 error。 而你是一个前端开发人员。在这个例子中，你专注于在Vue的框架下工作，你将会编写具有特定类名的Vue组件，这些类名使用设计师提供的CSS。 而未来，你可能也会需要构建具有相同CSS和流程的React或者Angular组件。这三个不同的框架或者说集成，都可以使用相同的validator的测试，这是核心的业务逻辑。
相同的validator的测试，指的是validataor属性的值是一个具有相同逻辑的验证函数，无论在什么平台，这个函数的核心逻辑都不会改变。
这个区别是很重要的。当我们使用测试框架方法(就像render方法)或Dom Api，我们是在验证Vue UI层工作是否如我们想的一样。而针对props的校验函数的测试则是针对我们的核心逻辑的测试。这些不同有时被称为"关注点"。一部分代码是关注UI，而另外则是关注核心逻辑。
如何辨别
分离他们是很棒的做法。这让你的代码更容易被理解和维护。这个概念被称为"关注点分离"。我们将贯穿整本书来重新讨论这个问题
如果你想要知道代码是关于UI的部分还是业务逻辑的部分。问一下自己这个问题："如果我将代码迁移到React上，我能否重新使用这份代码和对应的测试"
在这个例子中，你可以在迁移到React中复用验证函数validator和相关的测试。这个函数关心的是业务逻辑，而不需要关心这个函数相关的UI框架(当然了，仅仅是一个函数是不依赖于UI框架的)。无论是Vue或者React，我们都将支持三个信息的变量。而Vue原本的相关的组件和组件测试，都不得不用React重新编写。
理论上，你不想你的业务逻辑耦合到你选择的框架中。框架会变化，但是你的业务逻辑不大可能发生重大的变化。
糟糕的分离策略的坏处
我看过很糟糕的关注点分离导致了公司花费了上万的成本。他们的开发到了增加一个特性是具有相当风险并且开发效率很慢的程度，因为他们的核心业务跟UI结合得太过紧密。重写UI则意味着重写业务逻辑。
这里说明了，糟糕的关注点分离策略，会导致迭代的成本巨大且风险不可控。而原因则在于核心业务跟UI层结合的过于紧密
结尾
下一节是案例分析，其中举例了糟糕的代码结合方式是怎么样的。以及好的关注点分离如何帮助代码在不同框架之间迁移的。