拥抱敏捷开发(2)——更加敏捷

在敏捷开发的“洗脑”之下,有很多种实践的方法。不论哪种方法,测试都是敏捷的基础。

TDD与BDD

测试可以及时的验证代码的正确性,系统功能的健全与否,及时的反馈,及时的叫停。

所以,测试是保证敏捷的基础。采用大量的自动化测试,能够够快、够敏捷的保证软件质量。正是如此,才有了“代码即文档”的说法,测试代码成为了功能代码的文档。

TDD(Test-driven developmenet),即测试驱动开发,是敏捷开发中非常强调的。TDD倡导先编写测试,再完成功能的设计。其中的好处是,系统实现的代码都可以被测试覆盖到。

TDD可以保证系统能正确的运行,但是却无法保证是按照用户预期的方式运行。所以,就有了BDD(Behavior-driven developmenet)的概念,其目的就是把大家的理解一致化,这样最终开发出来的软件应该是符合用户预期的。

持续集成

有了TDD和BDD的保驾护航,软件开发“敏捷”了很多,能够及时的向用户的预期靠拢,并产出符合预期的软件。

但是,开发人员依然做着很多不“敏捷”的事情——频繁部署。假如我们向软件添加了很小的一个功能,我们需要做很多事情:拉取代码、修改代码、添加测试代码、构建程序(编译、链接等)、运行测试、提交代码(如果有冲突,还需要解决冲突)。

所以,为了再敏捷一些,有人提出了持续集成(CI,Continuous Integration)。

有了持续集成,多次添加小功能不必做重复的事情,让频繁部署成为易事。

可以把持续集成理解成一个Cron的定时任务,但它能做的远不止如此。

要想达到持续集成的效果,我们需要做以下事情:

  • 维护一个单一的代码库
  • 自动化构建的过程
  • 自动化测试的过程
  • 自动化部署
  • 每次提交都触发构建
  • 像主线提交代码
  • 在与生产环境一致的环境中测试
  • 人人都能看到现在的持续集成情况

参考链接:

  1. http://www.ltesting.net/ceshi/ruanjianzhiliangbaozheng/zlmx/mjkf/2012/0224/204194.html
  2. http://www.cnblogs.com/CloudTeng/archive/2012/02/25/2367565.html
  3. http://weavora.com/blog/2014/02/20/guide-continuous-integration-teamcity-behat/
  4. http://www.cnblogs.com/CloudTeng/archive/2012/02/25/2367565.html

-- EOF --