【DDD】学习笔记-薪资管理系统的测试驱动开发

news2024/11/19 3:22:37

回顾薪资管理系统的设计建模

在 3-15 课,我们通过场景驱动设计完成了薪资管理系统的领域设计建模。既然场景驱动设计可以很好地与测试驱动开发融合在一起,因此根据场景驱动设计的成果来开展测试驱动开发,就是一个水到渠成的过程。让我们先来看看针对薪资管理系统“支付薪资”领域场景分解的任务:

  • 确定是否支付日期
    • 确定是否为周五
    • 确定是否为月末工作日
      • 获取当月的假期信息
      • 确定当月的最后一个工作日
    • 确定是否为间隔一周周五
      • 获取上一次销售人员的支付日期
      • 确定是否间隔了一周
  • 计算雇员薪资
    • 计算钟点工薪资
      • 获取钟点工雇员与工作时间卡
      • 根据雇员日薪计算薪资
    • 计算月薪雇员薪资
      • 获取月薪雇员与考勤记录
      • 对月薪雇员计算月薪
    • 计算销售人员薪资
      • 获取销售雇员与销售凭条
      • 根据酬金规则计算薪资
  • 支付
    • 向满足条件的雇员账户发起转账
    • 生成支付凭条

根据任务分解驱动出来的时序图完整脚本则如下所示:

PaymentAppService.pay() {
    PaymentService.pay() {
        PayDayService.isPayday(today) {
            Calendar.isFriday(today);
            WorkdayService.isLastWorkday(today) {
                HolidayRepository.ofMonth(month);
                Calendar.isLastWorkday(holidays);
            }        
            WorkdayService.isIntervalFriday(today) {
                PaymentRepository.lastPayday(today);
                Calendar.isFriday(today);
            }
        }
        PayrollCalculator.calculate(employees) {
            HourlyEmployeePayrollCalculator.calculate() {
                HourlyEmployeeRepository.all();
                while (employee -> List<HourlyEmployee>) {
                    employee.payroll(PayPeriod);
                }
            }
            SalariedEmployeePayrollCalculator.calculate() {
                SalariedEmployeeRepository.all();
                while (employee -> List<SalariedEmployee>) {
                    employee.payroll();
                }
            }
            CommissionedEmployeePayrollCalculator.calculate() {
                CommissionedEmployeeRepository.all();
                while (employee -> List<CommissionedEmployee>) {
                    employee.payroll(payPeriod);
                }
            }
        }
        PayingPayrollService.execute(employees) {
            TransferClient.transfer(account);
            PaymentRepository.add(payment);
        }
    }
}

测试驱动的方向

有了分解的任务,也有了履行职责的各个角色构造型,现在是万事俱备只欠东风。让我们严格按照测试驱动开发的红绿黄节奏以及三定律开展领域实现建模。首先,我们要选择需要添加测试的新功能。场景驱动设计在分解任务时,是从外部代表业务价值的领域场景逐步向内推进和拆分的,这是一个从外向内的驱动设计方向;测试驱动开发则不同,为了尽可能避免编写需要模拟的单元测试,应该从内部代表业务实现的原子任务开始,先完成细粒度的自给自足的领域行为逻辑单元,然后逐步往外推进,直到完成满足完整领域场景的所有任务,这是一个从内向外的驱动开发方向:

71557437.png

这就意味着在开始测试驱动开发之前,我们需要选择合适的任务。需要考虑的因素包括:

  • 任务的依赖性
  • 任务的重要性

从依赖的角度看,并不一定需要优先选择前序任务,因为我们可以使用模拟的方式驱动出当前任务需要依赖的接口,而无需考虑实现。不过,基于场景驱动开发分解的任务层次,为其编写测试用例时,也应优先挑选无需访问外部资源的原子任务,即为聚合编写单元测试,因为它无需任何模拟行为。至于任务的重要性,主要是判断任务是否整个系统或模块的核心功能。在确定了领域场景的前提下,一个判断标准是确定任务是主要流程还是异常流程。通常而言,应优先考虑任务的主流程。

显然,支付薪资领域场景的核心功能是支付与薪资计算。由于支付由外部服务完成,剩下要实现的核心功能就是薪资计算。如果从原子任务开始挑选,应首先从内部的原子任务开始挑选,例如选择“根据雇员日薪计算薪资”原子任务:

  • 计算雇员薪资
    • 计算钟点工薪资
      • 获取钟点工雇员与工作时间卡
      • 根据雇员日薪计算薪资
    • 计算月薪雇员薪资
      • 获取月薪雇员与考勤记录
      • 对月薪雇员计算月薪
    • 计算销售人员薪资
      • 获取销售雇员与销售凭条
      • 根据酬金规则计算薪资

测试驱动开发的过程

编写失败的测试

现在需要为该子任务编写测试用例。根据钟点工薪资的计算规则,可以分为两个不同的测试用例:正常工作时长和加班工作时长。由于场景驱动设计已经确定了履行该原子任务职责的是 HourlyEmployee,遵循测试驱动开发的定律一“一次只写一个刚好失败的测试,作为新加功能的描述”,编写一个刚好失败的测试:

public class HourlyEmployeeTest {
    @Test
    public void should_calculate_payroll_by_work_hours_in_a_week() {
    }
}

按照 Given-When-Then 模式来编写该测试方法。首先考虑 HourlyEmployee 聚合的创建。由于钟点工每天都要提交工作时间卡,薪资按周结算,因此在创建 HourlyEmployee 聚合根的实例时,需要传入工作时间卡的列表。计算薪资的方法为 payroll(),返回结果为薪资模型对象 Payroll。验证时,需确保薪资的结算周期与薪资总额是正确的。故而编写的测试方法为:

    @Test
    public void should_calculate_payroll_by_work_hours_in_a_week() {
        //given
        TimeCard timeCard1 = new TimeCard(LocalDate.of(2019, 9, 2), 8);
        TimeCard timeCard2 = new TimeCard(LocalDate.of(2019, 9, 3), 8);
        TimeCard timeCard3 = new TimeCard(LocalDate.of(2019, 9, 4), 8);
        TimeCard timeCard4 = new TimeCard(LocalDate.of(2019, 9, 5), 8);
        TimeCard timeCard5 = new TimeCard(LocalDate.of(2019, 9, 6), 8);

        List<TimeCard> timeCards = new ArrayList<>();
        timeCards.add(timeCard1);
        timeCards.add(timeCard2);
        timeCards.add(timeCard3);
        timeCards.add(timeCard4);
        timeCards.add(timeCard5);

        HourlyEmployee hourlyEmployee = new HourlyEmployee(timeCards, Money.of(10000, Currency.RMB));

        //when
        Payroll payroll = hourlyEmployee.payroll();

        //then
        assertThat(payroll).isNotNull();
        assertThat(payroll.beginDate()).isEqualTo(LocalDate.of(2019, 9, 2));
        assertThat(payroll.endDate()).isEqualTo(LocalDate.of(2019, 9, 6));
        assertThat(payroll.amount()).isEqualTo(Money.of(400000, Currency.RMB));
    }

运行测试,失败:

56636479.png

让失败的测试刚好通过

在实现测试时,遵循测试驱动开发定律二“不写任何产品代码,除非它刚好能让失败的测试通过”,在实现 payroll() 方法时,仅提供满足当前测试用例预期的实现。什么是“刚好能让失败的测试通过”?以当前测试方法为例。要计算钟点工的薪资,除了它提供的工作时间卡之外,还需要钟点工的时薪,至于 HourlyEmployee 的其他属性,暂时可不用考虑;当前测试方法没有要求验证工作时间卡的有效性,在实现时,亦不必验证传入的工作时间卡是否符合要求,只需确保为测试方法准备的数据是正确的即可;当前测试方法是针对正常工作时长计算薪资,实现时就无需考虑加班的情况。实现代码为:

public class HourlyEmployee {
    private List<TimeCard> timeCards;
    private Money salaryOfHour;

    public HourlyEmployee(List<TimeCard> timeCards, Money salaryOfHour) {
        this.timeCards = timeCards;
        this.salaryOfHour = salaryOfHour;
    }

    public Payroll payroll() {
        int totalHours = timeCards.stream()
                .map(tc -> tc.workHours())
                .reduce(0, (hours, total) -> hours + total);

        Collections.sort(timeCards);

        return new Payroll(timeCards.get(0).workDay(), timeCards.get(timeCards.size() - 1).workDay(), salaryOfHour.multiply(totalHours));
    }
}

在编写让失败测试通过的代码时,要把握好分寸,既不要过度地实现测试没有覆盖的内容,也无需死板地拘泥于编写所谓“简单”的实现代码。简单并非简陋,既然你的编码技能与设计水平已经足以一次编写出优良的代码,就不必一定要拖到最后,多此一举地等待重构来改进。例如,在上述实现代码中,需要将工作总小时数乘以 Money 类型的时薪,你当然可以实现为如下代码:

new Money(salaryOfHour.value() * totalHours, salaryOfHour.currency())

然而,如果你已经熟悉迪米特法则,且认识到以数据提供者形式进行对象协作的弊病,就会自然地想到应该在 Money 中定义 multiply() 方法,而非通过公开 value 和 currency 的 get 访问器让调用者完成乘法计算。这时就可直接实现如下代码,而不必等着以后再来进行重构:

public class Money {
    private final long value;
    private final Currency currency;

    public static Money of(long value, Currency currency) {
        return new Money(value, currency);
    }

    private Money(long value, Currency currency) {
        this.value = value;
        this.currency = currency;
    }

    public Money multiply(int factor) {
        return new Money(value * factor, currency);
    }

    @Override
    public boolean equals(Object o) {
        if (this == o) return true;
        if (o == null || getClass() != o.getClass()) return false;
        Money money = (Money) o;
        return value == money.value &&
                currency == money.currency;
    }

    @Override
    public int hashCode() {
        return Objects.hash(value, currency);
    }
}

简单说来,在不会导致过度设计的前提下,若能直接编写出整洁的代码,又何乐而不为呢?只需要做到实现的代码仅仅能让测试刚好通过,不去过度设计即可。为了让测试方法通过,我们定义并实现了 HourlyEmployee、TimeCard 与 Payroll 等领域模型对象。它们的定义都非常简单,即使你知道 HourlyEmployee 一定还有 Id 和 name 等基本的核心字段,也不必在现在就给出这些字段的定义。利用测试驱动开发来实现领域模型,重要的一点就是要用测试来驱动出这些模型对象的定义。只要不会遗漏领域场景,就一定会有测试去覆盖这些领域逻辑。一次只做好一件事情即可。

现在测试变绿了:

82470824.png

在测试通过的情况下,先不要考虑是重构还是编写新的测试,而应提交代码。持续集成强调七步提交法,其基础就是进行频繁的原子提交。这样就能保证尽快将你的最新变更反馈到团队共享的代码库上,降低代码冲突的风险,同时也能为重构设定一个安全的回滚版本。

重构产品代码和测试代码

提交代码后,根据简单设计原则,我们需要检查已有实现与测试代码是否存在重复,是否清晰地表达了设计者意图。

先看产品代码,目前的实现并没有重复代码,但是 payroll() 方法中的代码 Collections.sort(timeCards); 会让人产生困惑:为什么需要对工作时间卡排序?显然,这里缺乏对业务含义的封装,直接将实现暴露出来了。排序仅仅是手段,我们的目标是获得结算薪资的开始日期和结束日期。由于返回的是两个值,且这两个值代表了一个内聚的概念,故而可以定义一个内部概念 Peroid。重构的过程是首先提取 beginDate 和 endDate 变量,然后定义 Period 内部类:

    public Payroll payroll() {
        int totalHours = timeCards.stream()
                .map(tc -> tc.workHours())
                .reduce(0, (hours, total) -> hours + total);

        Collections.sort(timeCards);

        LocalDate beginDate = timeCards.get(0).workDay();
        LocalDate endDate = timeCards.get(timeCards.size() - 1).workDay();
        Period settlementPeriod = new Period(beginDate, endDate);

        return new Payroll(settlementPeriod.beginDate, settlementPeriod.endDate, salaryOfHour.multiply(totalHours));
    }

    private class Period {
        private LocalDate beginDate;
        private LocalDate endDate;

        Period(LocalDate beginDate, LocalDate endDate) {
            this.beginDate = beginDate;
            this.endDate = endDate;
        }
    }

然后,再提取方法 settlementPeriod()。该方法名直接体现其业务目标,并将包括排序在内的实现细节封装起来:

    public Payroll payroll() {
        int totalHours = timeCards.stream()
                .map(tc -> tc.workHours())
                .reduce(0, (hours, total) -> hours + total);

        return new Payroll(
                settlementPeriod().beginDate,
                settlementPeriod().endDate,
                salaryOfHour.multiply(totalHours));
    }

    private Period settlementPeriod() {
        Collections.sort(timeCards);

        LocalDate beginDate = timeCards.get(0).workDay();
        LocalDate endDate = timeCards.get(timeCards.size() - 1).workDay();
        return new Period(beginDate, endDate);
    }

接下来,不要忘了对测试代码的重构。毫无疑问,创建 List 的逻辑可以封装为一个方法,不至于让测试的 Given 部分充斥太多不必要的细节:

 public class HourlyEmployeeTest {
    @Test
    public void should_calculate_payroll_by_work_hours_in_a_week() {
        //given
        List<TimeCard> timeCards = createTimeCards();
        Money salaryOfHour = Money.of(10000, Currency.RMB);
        HourlyEmployee hourlyEmployee = new HourlyEmployee(timeCards, salaryOfHour);

        //when
        Payroll payroll = hourlyEmployee.payroll();

        //then
        assertThat(payroll).isNotNull();
        assertThat(payroll.beginDate()).isEqualTo(LocalDate.of(2019, 9, 2));
        assertThat(payroll.endDate()).isEqualTo(LocalDate.of(2019, 9, 6));
        assertThat(payroll.amount()).isEqualTo(Money.of(400000, Currency.RMB));
    }

    private List<TimeCard> createTimeCards() {
        TimeCard timeCard1 = new TimeCard(LocalDate.of(2019, 9, 2), 8);
        TimeCard timeCard2 = new TimeCard(LocalDate.of(2019, 9, 3), 8);
        TimeCard timeCard3 = new TimeCard(LocalDate.of(2019, 9, 4), 8);
        TimeCard timeCard4 = new TimeCard(LocalDate.of(2019, 9, 5), 8);
        TimeCard timeCard5 = new TimeCard(LocalDate.of(2019, 9, 6), 8);

        List<TimeCard> timeCards = new ArrayList<>();
        timeCards.add(timeCard1);
        timeCards.add(timeCard2);
        timeCards.add(timeCard3);
        timeCards.add(timeCard4);
        timeCards.add(timeCard5);
        return timeCards;
    }
}

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处:http://www.coloradmin.cn/o/1466718.html

如若内容造成侵权/违法违规/事实不符,请联系多彩编程网进行投诉反馈,一经查实,立即删除!

相关文章

rem适配方案

目录 一&#xff0c;rem实际开发适配方案 二&#xff0c;rem适配方案技术使用&#xff08;市场主流&#xff09; 方案一&#xff1a; 方案二&#xff1a;​编辑 一&#xff0c;rem实际开发适配方案 ① 按照设计稿与设备宽度的比例&#xff0c;动态计算并设置html根标签的fo…

【自然语言处理-二-attention注意力 是什么】

自然语言处理二-attention 注意力机制 自然语言处理二-attention 注意力记忆能力回顾下RNN&#xff08;也包括LSTM GRU&#xff09;解决memory问题改进后基于attention注意力的modelmatch操作softmax操作softmax值与hidder layer的值做weight sum 计算和将计算出来的和作为memo…

Jetpack Compose 架构层

点击查看&#xff1a;Jetpack Compose 架构层 官网 本页面简要介绍了组成 Jetpack Compose 的架构层&#xff0c;以及这种设计所依据的核心原则。 Jetpack Compose 不是一个单体式项目&#xff1b;它由一些模块构建而成&#xff0c;这些模块组合在一起&#xff0c;构成了一个完…

基于YOLOv8/YOLOv7/YOLOv6/YOLOv5的人脸表情识别系统(附完整资源+PySide6界面+训练代码)

摘要&#xff1a;本篇博客呈现了一种基于深度学习的人脸表情识别系统&#xff0c;并详细展示了其实现代码。系统采纳了领先的YOLOv8算法&#xff0c;并与YOLOv7、YOLOv6、YOLOv5等早期版本进行了比较&#xff0c;展示了其在图像、视频、实时视频流及批量文件中识别人脸表情的高…

【elementUi-table表格】 滚动条 新增监听事件; 滚动条滑动到指定位置;

1、给滚动条增加监听 this.dom this.$refs.tableRef.bodyWrapperthis.dom.scrollTop 0let _that thisthis.dom.addEventListener(scroll, () > {//获取元素的滚动距离let scrollTop _that.dom.scrollTop//获取元素可视区域的高度let clientHeight this.dom.clientHeigh…

springboot+vue项目基础开发(17)路由使用

路由 在前端中,路由指的是根据不同的访问路径,展示不同的内容 vue Router的vue.js的官方路由 安装vue Router 再启动 在src下面新建router文件,创建index.js 代码 import {createRouter,createWebHashHistory} from vue-router //导入组件 import Login from @/views/Log…

SparkSQL学习03-数据读取与存储

文章目录 1 数据的加载1.1 方式一&#xff1a;spark.read.format1.1.1读取json数据1.1.2 读取jdbc数据 1.2 方式二&#xff1a;spark.read.xxx1.2.1 读取json数据1.2.2 读取csv数据1.2.3 读取txt数据1.2.4 读取parquet数据1.2.5 读取orc数据1.2.6 读取jdbc数据 2 数据的保存2.1…

RT-Thread-快速入门-2-时钟与定时器

时钟与定时器 阅读须知 定义与作用 定义 系统时钟 系统时钟在RT-Thread中用于管理时间&#xff0c;为系统运行提供时间基准。系统时钟由硬件计时器&#xff08;通常是CPU的内部定时器或外部定时器&#xff09;提供时钟节拍&#xff0c;这些时钟节拍通常以固定频率中断CPU&#…

opengl 学习纹理

一.纹理是什么&#xff1f; 纹理是一个2D图片&#xff08;甚至也有1D和3D的纹理&#xff09;&#xff0c;它可以用来添加物体的细节&#xff1b;类似于图像一样&#xff0c;纹理也可以被用来储存大量的数据&#xff0c;这些数据可以发送到着色器上。 采样是指用纹理坐标来获取纹…

npm install 失败,需要node 切换到 对应版本号

npm install 失败 原本node 的版本号是16.9&#xff0c;就会报以上错误 node版本问题了&#xff0c;我切到这个版本&#xff0c;报同样的错。降一下node&#xff08;14.18&#xff09;版本就好了 具体的方法&#xff1a;&#xff08;需要在项目根目录下切换&#xff09; 1. …

微服务学习

一、服务注册发现 服务注册就是维护一个登记簿&#xff0c;它管理系统内所有的服务地址。当新的服务启动后&#xff0c;它会向登记簿交待自己的地址信息。服务的依赖方直接向登记簿要Service Provider地址就行了。当下用于服务注册的工具非常多ZooKeeper&#xff0c;Consul&am…

JavaScript从零写网站《一瞬》开发日志20240223

产品介绍 一个无需注册能随时发布图片并配一段文字介绍的app&#xff0c;有时间线&#xff0c;用户在主页面向下滑动&#xff0c;可以看到被发布的若干图片&#xff0c;并且能够在每一个发布处做基本互动——评论&#xff0c;点赞 编程语言 本产品使用htmlcssJavaScript开发…

【Docker】构建pytest-playwright镜像并验证

Dockerfile FROM ubuntu LABEL maintainer "langhuang521l63.com" ENV TZAsia/Shanghai #设置时区 #安装python3依赖与下载安装包 RUN ln -snf /usr/share/zoneinfo/$TZ /etc/localtime && echo $TZ > /etc/timezone \&& apt update \&&…

Linux——进程概念

目录 冯诺依曼体系结构 操作系统 管理 系统调用和库函数 进程的概念 进程控制块——PCB 查看进程 通过系统调用获取进程标示符 通过系统调用创建进程 进程状态 运行状态-R ​编辑 浅度睡眠状态-S 深度睡眠状态-D 暂停状态-T 死亡状态-X 僵尸状态-Z 僵尸进程…

Open CASCADE学习|绘制砂轮

今天绘制一个砂轮&#xff0c;其轮廓由两条直线段和两段圆弧构成&#xff0c;圆弧分别与直线相切&#xff0c;两条圆弧之间相交而非相切。建模思路是&#xff1a;先给定两条直线段的起始点及长度&#xff0c;画出直线段&#xff0c;然后给定其中一圆弧的半径及圆心角&#xff0…

Linux之ACL访问控制列表

一、ACL权限的介绍 1.1 什么是ACL 访问控制列表&#xff08;ACL&#xff09;是一种网络安全技术&#xff0c;它通过在网络设备&#xff08;如路由器、交换机和防火墙&#xff09;上定义一系列规则&#xff0c;对进出接口的数据包进行控制。这些规则可以包含“允许”&…

解决IDEA中Maven下载依赖包过慢或报错的问题

由于公司项目迭代&#xff0c;越来越多的项目开始转型新版本&#xff0c;由于我对Java一直不感冒&#xff0c;但要顺应公司项目要求&#xff0c;遂自己要逐步开始完善Java相关的知识层面&#xff0c;此篇是我在学习SpringBoot时对一些不懂地方及遇到问题时的记录。 学习视频链…

Day 1.进程的基本概念、相关命令、函数结口

进程基本概念 一、进程&#xff1a; 程序&#xff1a;存放在外存中的一段数据组成的文件 进程&#xff1a;是一个程序动态执行的过程&#xff0c;包括进程的创建、进程的调度、进程的消亡 二、进程相关的命令 1.top 动态查看当前系统中所有的进程信息&#xff08;根据CPU…

基于PostGIS的慢查询引起的空间索引提升实践

目录 前言 一、问题定位 1、前端接口定位 2、后台应用定位 3、找到问题所在 二、空间索引优化 1、数据库查询 2、创建空间索引 3、geography索引 4、再看前端响应 总结 前言 这是一个真实的案例&#xff0c;也是一个新入门的工程师很容易忽略的点。往往在设计数据库的…

项目管理:如何成功完成一个项目

项目管理是一项重要的技能&#xff0c;它可以帮助你成功地完成一个项目。以下是一些关键的步骤&#xff0c;可以帮助你实现这一目标&#xff1a; 1. 明确项目目标&#xff1a;在开始项目之前&#xff0c;你需要明确项目的目标。这将有助于你制定一个明确的计划&#xff0c;并确…