Actionary

A man is valued by his works, not his words!

Exploding Fake in Unit Test

What’s exploding fake?

let’s see below source code firstly.

1
2
3
4
int a_stub(){
  fail("Boom!!! I shouldn't have been called!!!");
  return 0;
}

Even more popular:

1
2
3
4
5
6
int a_stub(){
  fail("Hey!!! I'm actually called! Now you can think about "\
  "what behaviour do you want me to have. Do you want me to "\
  "return a specific value?");
  return 0;
}

So where this exploding fake will be used? For example, you would like to add unit test case for legacy code, in order to pass the compilation, you have to add hundreds of stubs, but you do NOT have enough time to check what’s the stub purpose and return value, so you can make the stub be self exploding first. And then you can pass the compilation and add unit test case. Once there is stub exploding, then to check whether the stub shall be called, shall the stub have behaviour, and what’s return value.

Automatically generate exploding fake?

As we know, lots of stubs are needed during unit testing for legacy code, is there any easy way to generate exploding fake automatically?

Because the stub is the dependency’s function signature, actually, so, if you can get the dependancies’ signature, that will be easy to generate, for example, tool lizard could read all the functions signature, it will be good way to write a script to generate exploding fake.

Actually, James Grenning has already implement such script for the exploding fake generation: source>>

Does make sense to making exploding fake for dynamic programming language?

No, because the dynamic programming language is not complied and linked, it will be naturally failed once the dependency missing. In another words, it’s self-exploding type, :p

– EOF –

敏捷扫盲之XP(Extreme Programming)篇

背景

常常被很多朋友问到关于XP的问题,如什么是XP,什么又是工程实践,跟敏捷啥关系等等这样的问题。相信这些看似简单的问题,有很多人抱有同样的疑问。

本文旨在帮助工程师了解XP的知识点,更深入的话题请参考扩展阅读,对某一话题的辩论请移步至相应辩论区的文章,本文只做基本解释,不做更深入探讨。如果有陈述谬误,请在评论区注明,非常感谢。

什么是XP?1

XP是Extreme Programming的缩写,中文译为极限编程,是Kent Beck2等人在上世级九十年代发明的一种软件工程方法。极限编程是一种强调团队工作的工作方式,它是多种敏捷方式的一种。与Scrum不同的是,Scrum是一种工作方式的框架,从组织到团队的设计,而XP关注的是具体的工程技术实践。XP旨在通过工程实践的合理搭配使用,使开发者们能够自信地响应客户需求。强调反馈环机制,客户与研发团队之间的反馈环,测试与开发的反馈环,具体代码实现跟单元测试之间的反馈环,结对之间的反馈环。极限编程认为在软件研发过程中,变化是无所不在的,人们不应回避变化,而应该适应变化,通过对反馈的检视,去适应变化。 Alt 3

在XP中,常见的工程实践有:

测试驱动开发 (TDD: Test-Driven Development)4

也有人称之为单元测试先行。这是一种编程方式,在传统的瀑布软件开发中,人们习惯把单元测试当做测试的一部分,认为编程就是指产品代码的实现,只有在产品代码实现之后才能编写单元测试去验证代码的实现,在编程的过程中,人们更关注实现的部分,即所谓的HOW,单元测试是后置的。但是,在TDD中,单元测试被认为是描述单元需求(大部分是函数的需求)一种手段,测试用例成为一种自动化的单元测试代码,首先通过单元测试确定要实现什么,即所谓WAHT的部分,再实现产品代码,即HOW的部分,产品代码的编写始终以需求来驱动。

Alt

测试驱动开发的原理是:

  • 没有单元测试,不实现任何功能代码;
  • 只编写仅能代表一种失败情况的测试代码;
  • 只编写恰好能通过单元测试的产品代码。

验收测试驱动开发(ATDD)

ATDD是Acceptance Test-Driven Development的缩写。很多的工程师把它理解为自动化测试驱动开发(Automatic Test Driven Development),因为在很多公司在强调测试的自动化,其实这两者之间并没有太大的联系。ATDD强调的也是需求的澄清,通过举例的手段对用户故事需求进行澄清,再接着让这些例子变成一个个的测试用例,在功能需求被实现后,用这些测试用例去验证功能实现是否满足需求,而这需求的澄清和测试用例的实现是前置在具体的开发实现之前的。因为是通过举例的形式来描述功能的需求说明,也称之为SbE(Specification by Example,中文译为实例化需求),其同样要求测试前置。可以比较着TDD的概念来理解,TDD是对函数级别的需求说明,再驱动实现,而ATDD是对用户故事的级别的需求说明,分析,再驱动实现,他们都要求测试前置,即关注WHAT

Alt

而测试自动化是一种缩短反馈周期,实现回归测试(Regression Test)的手段。结合着持续集成系统,可以实现一键自动化的集成与部署。

结对编程

结对编程(Pair Programming),即两个人一起编写代码,共享显示器及键盘,一位同事担任的是navigator的角色,另一位是driver的角色。结对编程的前提是代码集体所有制(Collective Code Ownership),即代码为团队所共有,团队为代码的质量共同承担责任。一般人理解结对编程是两个人干一件事,是对人力资源的浪费,实则不然。因为:

  • 结对编程可以及时的完成结对代码审查,减少代码的缺陷率
  • 结对编程可以帮助人员的能力提升
  • 结对编程可以帮助攻关
  • 结对编程可以提高编程工作的专注度

想了解更多结对编程的内容,可以参考之前的文章:关于结对开发的那些事儿

持续集成 (Continuous Integration)

持续集成在XP的实践中占据着非常重要的位置。首先要了解什么是集成,然后再讨论持续的概念。集成无非就是收集、打包和验证的过程,这就是集成的概念。软件的代码由不同的人编写,需要将所有的代码从不同的位置收集到一处,然后进行编译,这就是一般SCM的概念(即软件配置管理),将编译出来的二进制文件部署到验证环境中,进行软件的验证,这就是一般传统理解的测试 5的概念。 为了让产品可以持续地交付到客户那里,从客户处获得客户的反馈,就有必要让产品可以持续地集成,加快集成的频率,缩短集成的周期,这就是持续的概念。为了让集成能够持续地运转,我们就有了持续集成系统,如Jekins帮助我们管理一个个持续集成的任务,Git或subversion做软件的配置管理,用自动化的编译工具对代码进行打包(因不同的开发语言而不同),自动化的单元测试,自动化的验收测试。提供一个清晰快速的反馈机制等等。进而可以演化为通过持续集成系统可以对整个开发工作进行可视化,精益方法运用到持续集成的工作中,指导项目的管理等等。进而延伸到持续部署、持续交付。

Alt 6

如果XP的各个工程实践是珍珠的话,那么串起这些珍珠项链的绳子就是持续集成。

如何学习和实践XP

除了了解这些基本概念外,需要了解这些实践背后的本质:反馈环 —— 通过获得反馈,持续改进的方式来适应变化的能力。还有就是不断实践,这不像学习别的东西,听个概念就可以跟人辩驳,XP是一门实践性非常强的方法,与Scrum和Kanban有着非常大的不同,Scrum是组织框架设计,Kanban适用于团队局部优化,而XP却是实打实地技术实践。小到可以从单个工程师编写代码养成良好地单元测试的习惯,再到两个人结对开发,进行可以做团队的持续集成,大到整个产品级别或系统级别的持续集成和交付。不积跬步无以至千里;不积小流,无以成江海。

结尾

最后希望本文能够对需要了解XP的同学有所帮助,也希望有更多的朋友能够一道学习,我们不只是要成为了一名把活干完的工程师,而是成为一名如何把活干好的工程师,不是成为了一名只想着构造的工程师,而是在构造之前会想要构造什么的工程师,我们是要制造产品,而不是次品,我们不是码农,而是匠人。

– EOF –


  1. 更多内容可以参考Extreme Programming: A gentle introduction

  2. Kent Beck也是敏捷宣言的十七位发起人之一,Test-Driven Development: By Example的作者

  3. 图片来源https://en.wikipedia.org/wiki/Extreme_programming#/media/File:Extreme_Programming.svg

  4. 可阅读Uncle Bob的The Cycles of TDD

  5. 这里指狭义理解的测试概念,测试的概念可以往验证、探索等各个方向延伸讨论,这里不做展开。

  6. 图片来自http://www.continuousautomation.com/

Customize Your Terminal

1. install zsh:

1
2
3
4
5
6
7
8
# install zsh-5.0.7
# prerequisite: gcc ncurses-devel readline-devel pcre-devel zlib-devel
curl -L http://jaist.dl.sourceforge.net/project/zsh/zsh/5.0.7/zsh-5.0.7.tar.bz2 | tar jx
cd zsh-5.0.7/
./configure --prefix=/usr/local/zsh/5.0.7 --enable-cap --enable-pcre --enable-multibyte --disable-gdbm
make
sudo make install
sudo alternatives --install /usr/local/bin/zsh zsh /usr/local/zsh/5.0.7/bin/zsh 50000

2. set the default shell to zsh:

2.1 update the /etc/shells, append zsh path there.

1
2
3
4
5
6
7
8
9
10
/bin/sh
/bin/bash
/sbin/nologin
/usr/bin/sh
/usr/bin/bash
/usr/sbin/nologin
/bin/tcsh
/bin/csh
/usr/local/bin/zsh
/usr/local/zsh

2.2 change the default shell to zsh

1
2
sudo chsh -s `which zsh`
sudo shutdown -r 0

3. Install the oh-my-zsh

https://github.com/robbyrussell/oh-my-zsh

1
sh -c "$(curl -fsSL https://raw.github.com/robbyrussell/oh-my-zsh/master/tools/install.sh)"

4. cutomize the theme of terminal

http://www.if-not-true-then-false.com/2012/solarized-linux/

1
2
git clone https://github.com/sigurdga/gnome-terminal-colors-solarized.git
gnome-terminal-colors-solarized/install.sh

– EOF –