用ABP只要加人即可马上加快项目进展(二)

2018年和1998年其中两大区别就是:

1. 前端蓬勃发展, 前后端分离是一个十分大的趋势.
2. 专门的测试人员角色被取消, 多出了一个很重要的角色, 产品经理

 

ABP只要加入即可马上加快项目进展, 选择前后端+产品经理分工结构会比前面的全栈篇好十分多!!! 因为:

1. 分工协作和流水线作业工作效率会远远比传统的个人全能型先进很多, 这个道理很多同学都懂, 我就不赘述了.
2. 前端快速和迅猛发展, 6个月发布一次大版本, 浏览器6周发布一次小版本, 导致传统程序员光是学习新技术就已经很吃力, 要谈精通更难了.请欣赏此图:
3. 招人扩展团队加快项目进度更容易了!!! 这才是重点!!!
   流水线作业减低每个人的技术难度, 让招人和培训新手更容易
   招校招生上手难度降低, 更容易招聘和更快能够有产出
   招社招生更容易, 质量更高, 特别现在是前端爆发期

 

接下来说说是怎么流水线作业的.

 

考虑到并不是所有同学都运用过BDD, 有很多同学只用过TDD的. 所以我分成两套流水线作业讲述. 

先说第一套没有BDD只有TDD的流水线作业工序吧:

1. 前后端一起定义接口
2. 后端写好C# interfaces用Swagger生成接口文档
3. 前端将后端写好的接口用refresh.bat生成前端ts proxy
4. 前后端各自干各自的活

 

以上流水线自然而然就运用了如下技术思想和技术点, 避免为了技术而技术, 为了思想而思想:

1. TDD
2. IOC/Mock
3. Interface

让技术和思想自然而然的为你服务, 而不是你为技术和思想服务.

 

大家看到, 在第一套流水线里面, 产品经理并没有参与进来. TDD是由开发人员写的, 与产品经理无关.

而在接下来的第二套流水线里, 产品经理通过运用BDD参与进来了:

1. 前端根据产品经理写好的Specflow的.feature文件用cucumber写BDD代码
2. 前后端一起定义接口和实现BDD的step definition代码
3. 后端写好C# interfaces用Swagger生成接口文档
4. 前端将后端写好的接口用refresh.bat生成前端ts proxy
5. 前后端各自干各自的活


这么说有可能会比较抽象, 在往后的日子里我会增加具体实际操作文章和视频.

 

与第一套流水线相比:

1. 产品经理参与进来, 给开发人员写明了详细操作步骤级的测试结构代码.
2. 开发人员不需要思考详细操作步骤, 只需要实现具体每个操作步骤.
3. 每个操作步骤是独立分割的, 遇到项目紧急时, 通过临时调人加人来加快项目进度变得更可行.
4. BDD与TDD相比, 天然的具备了结构性, 避免书写重复代码, 减少了测试代码的书写量.
5. 很多公共的测试代码可以分割出来, 让专门的技术专家去写 (这会在后面一节里提到)

 

可以看到, 第二套流水线比第一套流水线先进十分多.

 

那么有个问题, 产品经理有能力写BDD吗? 

从目前市场现状来看, 从测试人员改行过来做产品经理的, 是十分有能力写好BDD的.

反而开发人员很难写好BDD, 甚至写好TDD都很困难. 这也是为什么BDD和TDD在很多企业推广不起来的原因之一, 因为角色和能力错配了.

 

2010年开始, 行业里面逐步减少测试人员, 到了2015年, 这个趋势终于成了气候, 微软在2015年大量裁减测试人员成了这类现象的里程碑事件.

那么这么多被裁减的测试人员都去哪里了呢? 绝大多数人并没有离开IT这个这么火的行业, 很多都改为做产品经理了. 他们写测试用例的能力和写BDD能力是对标的, 并且切换很容易.

 

在这里要说明一下, 产品经理来源有两类:

1. 校招/美工/市场销售转过来的, 会用Axure等原型设计工具,这种情况应该由三个人结对编程写BDD.
2. 测试人员改行的, 这种人写测试用例的能力就很容易很天然的演变为写BDD的能力 

Talk is cheap, just show your code. 为了更形象的表现出产品经理有能力写BDD，我贴一个BDD .feature文件示例：

Feature: 登录
	此文件包含登录成功和失败的例子

Scenario: 输入正确的用户名和密码能够正常登录
	Given 我来到登录页面
	When 输入用户名"admin"
	And 输入密码"123qwe"
	And 点击"登录"按钮
	Then 跳转到首页

Scenario: 输入正确的用户名和错误的密码则登录失败
	Given 我来到登录页面
	When 输入用户名"admin"
	And 输入密码"111111"
	And 点击"登录"按钮
	Then 依旧停留在登录页面
	And 提示"用户名或密码错误"

Scenario: 输入错误的用户名则登录失败
	Given 我来到登录页面
	When 输入用户名"admin"
	And 输入密码"111111"
	And 点击"登录"按钮
	Then 依旧停留在登录页面
	And 提示"用户名或密码错误"

Scenario: 输入空的用户名则提示要输入空用户名
	Given 我来到登录页面
	And 点击"登录"按钮
	Then 依旧停留在登录页面
	And 提示"用户名必须填写"

Scenario: 输入空的密码则提示要输入空密码
	Given 我来到登录页面
	When 输入密码"admin"
	And 点击"登录"按钮
	Then 依旧停留在登录页面
	And 提示"密码必须填写"

　　从这个示例我们可以看到，除了少数几个大家都看得懂的英语单词外，全部都可以为中文，全部都可以为人类可以识别的语言，没有一行代码！不需要产品经理会写代码。

除了以上这个好处外，BDD在程序员方面还带来了天然的很良好的测试代码结构。让我们看一下示例：

using TechTalk.SpecFlow;

namespace Bowling.SpecFlowXUnit.StepDefinitions
{
    [Binding]
    public sealed class 公用测试代码
    {
        [When(@"输入密码""(.*)""")]
        public void When输入密码(string p0)
        {
            //ScenarioContext.Current.Pending();
            //具体测试代码
        }

        [Given(@"我来到登录页面")]
        public void Given我来到登录页面()
        {
            //ScenarioContext.Current.Pending();
            //具体测试代码
        }

        [When(@"输入用户名""(.*)""")]
        public void When输入用户名(string admin0)
        {
            //ScenarioContext.Current.Pending();
            //具体测试代码
        }

        [When(@"点击""(.*)""按钮")]
        public void When点击按钮(string 登录0)
        {
            //ScenarioContext.Current.Pending();
            //具体测试代码
        }

        [Then(@"跳转到首页")]
        public void Then跳转到首页()
        {
            //ScenarioContext.Current.Pending();
            //具体测试代码
        }

        [Then(@"依旧停留在登录页面")]
        public void Then依旧停留在登录页面()
        {
            //ScenarioContext.Current.Pending();
            //具体测试代码        
        }

        [Then(@"提示""(.*)""")]
        public void Then提示(string 用户名或密码错误0)
        {
            //ScenarioContext.Current.Pending();
            //具体测试代码
        }

        [Given(@"点击""(.*)""按钮")]
        public void Given点击按钮(string 登录0)
        {
            //ScenarioContext.Current.Pending();
            //具体测试代码
        }
    }
}

　　从上面示例可以看到，以上代码结构都可以用Specflow自动生成，程序员不需要像TDD一样要自己去组织测试代码结构，这也是BDD优于TDD的很大一个特点。这里有个小秘诀，自动生成之后把Class Name全改为一致然后加上Partial关键字就可以有重复Step Definition会编译不通过提醒。

这系列文章是实战文章，所以不止止停留在理论上，在实际运用过程中会遇到各种问题。比如：

1. 如何在.NET Core下安装Specflow.
2. .NET Core里跑Specflow - 可以跑集成测试和单元测试.