敏捷与测试驱动开发

1. Agile Manifesto（敏捷宣言）

1.1. 4 values

• Individuals and interactions over processes and tools（个体和互动高于流程和工具）
• Working software over comprehensive documentation（工作的软件高于详尽的文档）
• Customer collaboration over contract negotiation（客户合作高于合同谈判）
• Responding to change over following a plan（响应变化高于遵循计划）

1.2. 12 principles

• Our highest priority is to satisfy the customer through early and continuous delivery of valuable software(我们最重要的目标，是通过持续不断地及早交付有价值的软件使客户满意)
  • 与传统的产品开发方法不同的是，敏捷原则鼓励尽量缩短从构思到发布的时间。尽快将产品送到客户手中。成功地做到这一点，意味着产品经理能够迅速将最小可行产品（minimum viable product, MVP）推出，并利用它来获得真正客户的反馈。这些反馈会被反馈到产品开发过程中，并被用来指导未来的发布
• Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage(欣然面对需求变化，即使在开发后期也一样。为了客户的竞争优势，敏捷过程掌控变化)
• Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.(经常地交付可工作的软件，相隔几星期或一两个月，倾向于采取较短的周期)
• Business people and developers must work together daily throughout the project(业务人员和开发人员必须相互合作，项目中的每一天都不例外)
• Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done(激发个体的斗志，以他们为核心搭建项目。提供所需的环境和支援，辅以信任，从而达成目标)
• The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.(不论团队内外，传递信息效果最好效率也最高的方式是面对面的交谈)
• Working software is the primary measure of progress(可工作的软件是进度的首要度量标准)
  • 完美的、详细的文档对于工作中的软件来说是次要的。这种心态促使我们迅速将产品推向市场，而不是让文档或 “不完美就不算完成 “的心态成为一个瓶颈。衡量成功的最终标准是一个客户喜爱的工作产品。
• Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely(敏敏捷过程倡导可持续开发。责任人、开发人员和用户要能够共同维持其步调稳定延续)
• Continuous attention to technical excellence and good design enhances agility.(坚持不懈地追求技术卓越和良好设计，敏捷能力由此增强)
• Simplicity–the art of maximizing the amount of work not done–is essential.(以简洁为本，它是极力减少不必要工作量的艺术)
• The best architectures, requirements, and designs emerge from self-organizing teams(最好的架构、需求和设计出自自组织团队)
• At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. (团队定期地反思如何能提高成效，并依此调整自身的举动)

Test-driven development is a practice commonly used by agile development teams, but it is not a core principle.

1.3. YAGNI” (You Ain’t Gonna Need It)

The YAGNI principle is about maximising work not done. It states that a feature should only be implemented when it is clear that it is required, and developers should not implement something on their assumption that it will be.

2. Agile development

2.1. Scrums

Scrum is a simple Agile framework that is used for managing complex product

Scrum是一个简单的敏捷框架，用于管理复杂的产品

• essential part of Scrum：time-boxed sprints

  Regular, defined periods of development activity is an important feature of scrum. Daily meetings (scrums) take place, but they do not have to be ‘stand-ups’. Particular engineering practices, like automated testing, are not specified in scrum.

2.1.1. Scrum Events

Prescribed events are used to create regularity and minimize the need to hold a meeting that’s not defined in scrum

规定的事件被用来创造规律性，并尽量减少举行scrum中没有定义的会议的需要

• sprint
• daily scrum

2.1.2. sprint

A sprint is a time-box of one month or less, in our case 2 weeks, during which the team have to finish a usable, potentially releasable products.

一个冲刺是一个月或更短的时间，在我们的例子中是2周，在此期间，团队必须完成一个可用的、有可能被释放的产品。

2.1.3. daily scrum

Daily scrum is a 15-minute time discussion that is held every day to make sure everyone is at the same page, synchronized, and to plan for the next daily scrum.

每天的Scrum是一个15分钟的讨论，以确保每个人都在同一起跑线上，同步进行，并为下一次的Scrum做计划。

2.2. Technique Practice

• we must integrate testing into the development process. Of course TDD is a great way to do this and this is what we do in this course.
  • to integrate testing into the development process is that testing can act as a probe(探针) that lets us know where we are and whether we are done.
  • And continuous testing gives us continuous feedback - both internal and external feedback.
    • 内部反馈的一个例子可能是：这个提高速度的想法可行吗？
    • 而外部反馈可能来自于客户。这是客户想要的吗？
  • 任何留在最后的东西都会在时间用完后被放弃或减少，所以把测试留到最后有可能根本没有做任何测试
  • You can also make running your tests using Continuous Integration（持续集成） or CI.
    • This is a regular build process triggered when you check your code into your repository.
• we should follow good engineering practices.
  • 鼓励人们学习代码的其他部分，并确保他们在写代码时尽可能让别人理解，而不是仅仅局限在自己的user story上
  • One of the side effects（副作用） of collective ownership is that it increases the project’s Bus Factor（巴士因子）.

    一个项目或项目至少失去若干关键成员的参与（“被巴士撞了”，指代职业和生活方式变动、婚育、意外伤亡等任意导致缺席的缘由）即导致项目陷入混乱、瘫痪而无法存续时，这些成员的数量即为巴士系数

• we should normalize collective ownership of the code
  • 我们应该将代码的集体所有权规范化
• we should pay off technical debt whenever we can

  技术负债（英语：Technical debt），又译技术债，也称为设计负债（design debt）、代码负债（code debt），是程序设计及软件工程中的一个比喻。指开发人员为了加速软件开发，在应该采用最佳方案时进行了妥协，改用了短期内能加速软件开发的方案，从而在未来给自己带来的额外开发负担。这种技术上的选择，就像一笔债务一样，虽然眼前看起来可以得到好处，但必须在未来偿还。软件工程师必须付出额外的时间和精力持续修复之前的妥协所造成的问题及副作用，或是进行重构，把架构改善为最佳实现方式。

  • 重构是还债最常见的方式，其余还包括增加测试用例等

2.3. self-organising team

Unlike traditional teams, the self-organizing empowered teams are not directed and controlled from the top; rather they evolve from team members participating actively & collectively in all the Scrum practices and events.

• A top-down management style is a threat to self-organising team

2.3.1. roles

The scrum master is responsible for facilitating progress, but not for managing or leading the team, which is self-organising. The product owner takes responsibility for ensuring requirements are met.

Scrum主管负责促进进展（确保工作公平分配等），但不负责管理或领导团队——团队是自我组织的。产品负责人负责确保需求得到满足

• Product Owners manage the product backlog and ensure the company gains maximum value from the product.
• 注意agile每个人是平等的，没有所谓的team leader

2.4. Plan

The initial planning to discuss the works to be performed and complete for each Sprint. This discussion will be held by the entire team. This discussion will also set up the initial sprint backlog and user stories

初步规划，讨论每个Sprint要执行和完成的工作。这个讨论将由整个团队进行。这个讨论也将建立最初的冲刺积压和用户故事。

• At which of the following times would a developer write down implementation details
  • During sprint planning. Within a scrum project, the first time implementation is considered in detail is at the sprint planning stage, when the team have committed to providing the functionality.

2.4.1. User story（用户故事）

用户故事（英语：User story）是软件开发和项目管理中的常用术语，通常是一段简单的功能表述。以客户或使用者的观点撰写下有价值的功能、引导、框架来与使用者进行互动，进而推动工作进程。可以被认为是一种规格文件，但更精确而言，它代表客户的需求与方向。以该用户故事来反应对象在组织内的其工作职责、范围、需要进行的任务等。

• 用户故事在敏捷开发方法中用来定义系统需要提供的功能和实现需求管理。
• example:

  User story: make the UI adaptable
  
  Description:
  As an Academic,
  I want to have a UI that looks nice on a phone/tablet,
  so that I can use the app when I'm travelling.

2.4.2. Story points

A story point is a metric, more abstract than say ‘an hour’, used in agile project management to figure out the implementation difficulty of a certain user story. Fundamentally, it’s a number that tells everyone on the team how challenging a story is, based on factors such as its complexity, risks and efforts involved.

故事点是一个衡量标准，比 “一小时 “更抽象，在敏捷项目管理中用来计算某个用户故事的实施难度。从根本上说，它是一个数字，告诉团队中的每个人一个故事有多大的挑战性，基于它的复杂性、风险和涉及的工作等因素

Story point estimation is based on three main components:

• Risk includes demands that are vague(模糊), dependendencies and random changes.

• Complexity is related to how difficult a feature is to develop for example.

• Repetition is determined by how well the team member knows a feature and how monotonous the tasks are.

  由团队成员对一个功能的了解程度和任务的单调程度决定的

• document confirmed details about a story

  • In acceptance tests. Defining acceptance tests pins down what the user expects from a feature in an unambiguous form, making it straightforward to check functionality against them

2.4.3. epic

• An epic is a single user story, but one that might take a long time to implement, and that might ultimately be broken down into a number of smaller stories. For example, ‘obtain feedback from the user’ on an ecommerce site may be broken down into the stories, ‘provide contact details’, ‘create web form for complaints’, ‘create web form for queries’ etc.

2.4.4. spike

A spike is a user story for which the team cannot estimate the effort needed. In such a case, it is better to run time-boxed research, exploration to learn about the issue or the possible solutions. As a result of the spike, the team can break down the features into stories and estimate them.

• 尖峰是一个用户故事，团队无法估计所需的工作量
• 作为尖峰的结果，团队可以将功能分解为故事，并对其进行评估

• 需要通过iterative approach来解决

---

2.4.5. Product Backlog

整个项目必须做的所有事情

• 一个有效的产品积压将清单上的每个项目分解成一系列的步骤，以帮助开发团队。
• 必须有一个持续时间，所以团队知道什么时候开始任务，以及在他们必须完成任务之前有多长时间。
• 它总是处于变化的状态

Product backlog items take a variety of formats, with user stories being the most common. The team using the product backlog determines the format they chose to use and look to the backlog items as reminders of the aspects of a solution they may work on.

• Complement estimates
• Requirements
• Prioritisation infomation
• Not include implement details

2.4.6. Sprint backlog

The sprint backlog is like a subset of the product backlog

• 它只包含那些可以在每个敏捷冲刺期间完成的项目
• Unlike the product backlog, though, the sprint backlog is unchanged during the period of the sprint

2.5. Design

2.5.1. paper-prototyping

A software product can be tested before implementation starts, by using a method like ‘paper-prototyping’ or wire-framing, which allow the user interface to be trialled before it is built.

2.6. Development

2.6.1. Burn down chart(燃尽图)

A Burn Up Chart is a tool used to track how much work has been completed, and show the total amount of work for a project or iteration. It’s used by multiple software engineering methods but these charts are particularly popular in Agile and Scrum software project management. The completed work and total work is shown on the vertical axis in whatever units a project team feels works best, i.e., work-hours, work-days, story points, or any other work unit. The horizontal access displays time, usually in days, weeks, or iterations (sprints).

燃烧图是一种用于跟踪已完成的工作的工具，并显示一个项目或迭代的总工作量。 它被多种软件工程方法所使用，但这些图表在敏捷和Scrum软件项目管理中特别流行。已完成的工作和总工作量在纵轴上以项目组认为最有效的单位显示，即工作小时、工作天、故事点或任何其他工作单位。 横轴显示的是时间，通常以天、周、或迭代（冲刺）为单位。

2.7. Feedback

2.7.1. stand up

站会（英语：stand-up meeting，或stand-up），是一种参与者以站姿进行的会议。这种会议以站姿这种不太令人舒适的姿势目的是为了让会议时间变短

• 对开发进度进行汇报和许诺
• 讨论潜在的技术挑战、任务分配以及时间安排

2.7.2. sprint review && retrospective

• A sprint review updates customers about progress on the project. So the customers decides which practices worked best during the sprint
  • New software features would be explained during a sprint review
• Sprint Retrospective is an opportunity for the team to inspect itself and create a plan for improvement to be enacted in the next sprint.
  • The software development process is examined by the team internally in a retrospective.

2.7.3. Scaled agile framework(基于大规模的敏捷框架)

扩展的敏捷框架（SAFe）是一套组织和工作流程模式，旨在指导企业扩展精益和敏捷实践

The SAFe planning cycle recommends including an additional iteration after a release, allowing teams
to improve their practices and are ready for the next planning increment

todo

• ease the demands on their time. If multiple teams are planning their sprints at the same time then the product owner could become a bottleneck
• take advantage of different specialist expertise.
• share the product backlog
• partion the product backlog
  • Two simple options for this are views and themes.
  • The key with both of these partitioning methods - views and themes - is that the stories themselves remain on, and are prioritized as part of, the single backlog.

Underlying（基本） principles of SAFe

• Take an economic view
• Apply systems thinking
• Assume variability; preserve options
• Build incrementally with fast integrated learning cycles
• Base milestones on objective evaluation of working systems
• Visualize and limit work-in-progress, reduce batch sizes, and manage queue lengths
• Apply cadence (timing), synchronize with cross-domain planning
• Unlock the intrinsic motivation of knowledge workers
• Decentralize decision-making
• Organize around value

2.8. Trunk Based Development (基于主干的开发模式)

2.8.1. The Problems with Git Flow

• Merge Conflicts
• Feature Separation
  • You cannot test the combination of two features until they are merged into one branch
• The Unpredictable Release
  • It is impossible to know how much time you will need for a release if the feature branches are not merged yet

You only have one main branch, the trunk (also called master or mainline). There is no develop branch anymore. Also no long-living feature branches! All your commits are merged into the trunk as soon as possible, at least once a day. By merging to the trunk so quickly, merge conflicts become very rare. Using short-living branches is one of the 4 Simple Tricks to Avoid Merge Conflicts.

The big question is: How can you avoid to get an unstable master branch if you push your code into it every day, even if a feature is not finished, yet?

2.8.2. solution

We started to use feature toggles – little switches in the source code that decide whether a feature is active or not.

As long as a feature is not ready to be released, it is disabled. That allows us to already push it into the develop branch without breaking anything. Developers and manual testers can enable every feature in some settings which are hidden to the normal users.

A/B testing. Since every feature toggle can be controlled remotely we have the possibility to enable a feature only for a part of our user base and disable it for the others. Doing that we can see how well a feature really performs. We can test new features on small test groups and then decide whether we should enable it for everybody or remove it if we see a negative impact

if ( FeatureManager.isFeatureEnabled("NewLoginForm") )
{
    openNewLoginForm()
}
else
{
    openOldLoginForm()
}

2.9. Verification

In state verification you have the object under testing perform a certain operation, after being supplied with all necessary collaborators. When it ends, you examine the state of the object and/or the collaborators, and verify it is the expected one.

In behaviour verification, on the other hand, you specify exactly which methods are to be invoked on the collaboratos by the SUT, thus verifying not that the ending state is correct, but that the sequence of steps performed was correct

2.10. Continuous delivery(持续交付)

• feature toggles同样可用于实现持续交付

2.11. Limitations of Agile Methodologies

• it is not suitable for maintenance（lack of documentation）
• agile Methodologies depend heavily on the user involvement, and thus, the success of the project will depend on the cooperation and communication of the user（项目的成功将取决于用户的合作和沟通）
• agile methodologies concentrate work quality on the skills and behaviors of the developers, as the design of the modules and sub-modules are created mainly by single developer.
  • 敏捷方法论对于成员数量相对较少（不低于3人，不超过9人）的团队来说效果最好，因此，对于成员数量较多的团队来说，敏捷方法论不会有好的效果

采用敏捷开发必须要先满足以下条件：

1. cooperation and face to face relation between the customers and the development team
2. evolving and changing requirements of the project
3. developers having good individual skills and experiences

---

3. Test-driven development(TDD)

测试驱动开发，英文全称Test-Driven Development，简称TDD，是一种不同于传统软件开发流程的新型的开发方法。 它要求在编写某个功能的代码之前先编写测试代码，然后只编写使测试通过的功能代码，通过测试来推动整个开发的进行。 这有助于编写简洁可用和高质量的代码，并加速开发过程

特点

• Reduced regressions

• Lean code

• High test coverage

• reasons to use Test-Driven Development: TDD provides a clear and unambiguous progress meter(进度表). If we know how many features are fully tested and complete, then we know how far we are through development. This also improves the quality of our estimations and means that we can include the customer in daily development decisions. TDD does provide useful quality assurance for our code as we write it, but it doesn’t mean we can ignore quality assurance of the software as a whole.

• test assumes nothing about previously executed tests

3.1. Test doubles（测试替身）

• SUT: System Under Test
• collaborator objects: secondary objects
• Tests Doubles(测试替身):

  In automated unit testing, it may be necessary to use objects or procedures that look and behave like their release-intended counterparts, but are actually simplified versions that reduce the complexity and facilitate testing. A test double is a generic (meta) term used for these objects or procedures.

type

• Test stub（桩）
  • Stub is an object that holds predefined data and uses it to answer calls during tests. It is used when we cannot or don’t want to involve objects that would answer with real data or have undesirable side effects.
• Mock object
  • 在各种测试桩中，只有moc提供了behavior verification行为验证
  • Python 中 Mock 到底该怎么玩？一篇文章告诉你（超全） - CDA数据分析师的文章 - 知乎

    在测试验证过程中，对于那些尚未完成或不稳定的对象，用一个虚拟对象来替代，以便测试的测试方法，因此，这个虚拟的对象是 Mock 对象，Mock 对象是真实对象在调试期间的代替品

    优势

    • 前、后端并行开发
    • 模拟无法访问的资源
    • 隔离系统，避免脏数据干扰测试结果

    '''
    假设 Product 类中有 2 个方法
    - get_product_status_by_id
    - buy_product
    其中，
    - get_product_status_by_id 方法还没有实现
    - buy_product 方法依赖于 get_product_status_by_id 方法的返回值
    '''
    import unittest
    from unittest import mock
    
    from unittest_mock.product_impl import Product
    
    class TestProduct(unittest.TestCase):
    
        def test_success(self):
            # 成功结果
            mock_success_value = {"id": 1, "name": "苹果", "num": 23}
    
            product = Product()
    
            # get_product_status_by_id还没写好，故mock
            product.get_product_status_by_id = mock.Mock(return_value=mock_success_value)
    
            # 调用要测试的函数buy_product
            assert product.buy_product(1).get("status") == 0
    
    if __name__ == "__main__":
        unittest.main()

• Test spy
  • The spy is closest to a mock, and it can record some information about how it was called, but a mock contains expectations which form a specification of the calls they are expected to receive.
• Fake object（伪件）
  • Fakes are objects that have working implementations, but not same as production one. Usually they take some shortcut and have simplified version of production code.
  • Stub and mock are both fakes
• Dummy object（傀儡）

---

---

3.1.1. stub vs test

• A stub is a test double that returns values to the SUT.
• A mock is a test double that a test uses to verify that the SUT correctly invokes a dependency.

---

• a stub is to notice that the stub can never fail the test.
• On the other hand, the test will use a mock object to verify whether the test failed or not.

3.2. test fixtures (测试环境)

A test fixture is an environment used to consistently test some item, device, or piece of software. Test fixtures can be found when testing electronics, software and physical devices

---

如果在测试前需要准备环境，测试后恢复环境，或者每次测试前的步骤都是一样的，可以采用Test fixture，使代码更简洁

• A data file.
• A pre-populated database.
• A random seed.

  A random seed would be used to ensure that a pseudo-random number generator output consistant numbers, so ensuring that tests relying on random numbers are repeatable

test fixtures的例子包括用特定的已知数据集加载数据库，擦除硬盘并安装一个已知的清洁操作系统，复制特定的已知文件集，或准备输入数据以及设置和创建模拟对象。

• 更多参考：Pytest之Fixture参数详解及使用_totorobig的博客-CSDN博客_pytest.fixure

import pytest
# fixture函数(类中) 作为多个参数传入
@pytest.fixture()
def login():
    print("打开浏览器")
    a = "account"
    return a
    
@pytest.fixture()
def logout():
    print("关闭浏览器")

class TestLogin:
    #传入lonin fixture
    def test_001(self, login):
        print("001传入了loging fixture")
        assert login == "account"

    #传入logout fixture
    def test_002(self, logout):
        print("002传入了logout fixture")

    def test_003(self, login, logout):
        print("003传入了两个fixture")

    def test_004(self):
        print("004未传入任何fixture哦")

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

3.3. Limitation of TDD

you cannot drive all programming tasks by tests. This has its roots in the fact that TDD relies on unit tests, but the fact that it relies on unit tests is not a limitation in itself. Bug fixing and maintenance is an area where TDD comes into its own: you can use the bug as failing test data, and when that test passes you know the bug has been fixed.

你不能用测试来驱动所有的编程任务。这根源于TDD依赖于单元测试的事实，但它依赖于单元测试的事实本身并不是一种限制。错误修复和维护是TDD发挥作用的一个领域：你可以把错误作为失败的测试数据，当该测试通过时，你就知道该错误已经被修复。

• slow process
  • they often have the sensation that the implementation of latest features takes longer if developers write code that will not find themselves within the product half the time. It helps if the entire team agrees on the importance of unit tests.
• tests need to be maintained because the code has got to
  • Whenever requirements change, you would like to vary the code and tests. But you’re working with TDD. this suggests that you simply got to change the tests first then make the tests pass
  • thus more time spent
• No silver bullet
  • 用tdd并不保证让你的bug完全消失

3.4. refactoring at different levels

3.5. Integration testing

集成测试

• Integration testing is conducted to evaluate the compliance of a system or component with specified functional requirements
• It occurs after unit testing and before system testing.

目的

1. 在把各个模块连接起来时，穿越模块接口的数据是否会丢失。
2. 各个子功能组合起来，能否达到预期的要求的父功能。
3. 一个模块的功能是否会对另一个模块的功能产生不利的影响。
4. 全局数据结构是否有问题，会不会被异常修改。
5. 单个模块的误差积累起来，是否会放大，从而达到不可接受的程度。

3.5.1. vs unit test

While unit testing is used to find bugs in individual functions, integration testing tests the system as a whole. These two approaches should be used together, instead of doing just one approach over the other. When a system is comprehensively unit tested, it makes integration testing far easier because many of the bugs in the individual components will have already been found and fixed

3.6. Regression test

回归测试是指修改了旧代码后，重新进行测试以确认修改没有引入新的错误或导致其他代码产生错误。自动回归测试将大幅降低系统测试、维护升级等阶段的成本。

回归测试作为软件生命周期的一个组成部分，在整个软件测试过程中占有很大的工作量比重，软件开发的各个阶段都会进行多次回归测试。在渐进和快速迭代开发中，新版本的连续发布使回归测试进行的更加频繁

3.7. End to End test(System testing)

• System testing is testing conducted on a complete integrated system to evaluate the system’s compliance with its specified requirements.
  • e.g. Mobile-device testing

3.8. Acceptance testing（验收测试）

• blackbox testing
• Dynamic analysis

3.8.1. vs Unit Test

Unit tests, which are written by programmers, for programmers, in a programming language. And acceptance tests, which are written by business people (and QA), for business people, in a high level specification language

---

单元测试深入到代码中，测试独立的单元。事实上，程序员必须花大力气将系统的各个组成部分解耦，以便独立测试它们。因此，单元测试很少对系统的大块集成部分进行测试。

另一方面，验收测试对系统中更大的集成块进行操作。他们通常从系统的输入（或非常接近输入的点）驱动系统，并从输出（或再次，非常接近输出）验证操作

4. 参考

• Test Doubles - Fakes, Mocks and Stubs
• From Git Flow to Trunk Based Development