Skip to content


u9 魔兽助手 4.3 zip 下载

u9 魔兽助手 4.3 zip 下载

u9wsh43.zip

Posted in 全部. Tagged with , , .

魔兽争霸 RPG DOTA 中文版 地图 下载 AI 6.67

DOTA v6.67c 中文版 下载

dota-allstars-v667c.w3x

DOTA v6.67b  AI 中文版 下载

dota-allstars-v667b-rev2c-ai-cn

Posted in 兴趣爱好. Tagged with , .

《大道至简》读后感

我是一个不善写作的人,特别是当描述的问题十分复杂时。然而今天一口气通读《大道至简》这本书后,颇有些感悟,特别是结合最近一段时间自己的工作经验,以及今天进行的Q2 review后。

迫使我突然拜读这本书的原因主要有三个:一是周爱民大牛已经加盟支付宝公司,他的大作我还未阅读过;二是twitter上有人聊到正在阅读此书;三是今天恰好进行Q2的review,下阶段我十分迫切的需要在软件分析和设计上有所提升。

一口气通读下来后,能够留在我短时记忆十分糟糕的大脑里的就只剩下:语言只是工具、boss是“经营者”、软件工程中作者的一些感悟。

先说说语言只是工具吧,作者提到为那些争论语言孰优孰劣的开发人员感到可悲。然而,能够得出这样一个结论之前的人,恰恰之前正在经历这样一个阶段。作为JAVA开发人员来讲,使用何种开发语言的确已经显得不那么重要了,因为任何语言都是可以学习的,他们只是工具,或者说是知识,真正转化为生产力的, 还是需要用语言来实现系统、完成系统需求,让客户满意。不善思考的程序员或许需要很长时间绕出这个圈子,然而最近两三年的软件行业的变化(Ruby,Groovy,Scala,JRuby,Python…),不得不让每个业内的开发人员思考这样一个问题:“需要学习那一种语言才不被淘汰?”这就迫使我们每个人都去思考语言的真正意义。现如今,每种语言都有自己的强项以及局限性,新的语言可能在语法结构、动态性方面有无可比拟的优势,但是它们真正适用使用目前现行的系统吗?它的学习成本值得吗?它能解决所有问题吗?显然答案是否定的,我们需要思考每种语言的试用范围,让“锤子”去解决钉钉子的问题,而不是打开啤酒瓶!

boss是“经营者”,这个论点我是非常赞同的。毕竟开发人员和boss所处的立场不同,角色不同。项目中,甚至公司里的每个成员的职责都是不同,如何很好的协作,是考验每一个一个公司(特别是中型和大型团队)管理和组织水平的。作者提到体制的问题:“体制的内涵是分两个方面的,其一是“体”,即“体系”;其二是“制”,即“制度””,确实给我很大的启发,体制如果分开来看,的确可以解释管理中一些问题。“皮之不存,毛将焉附。没有确定的组织机构,又如何能指望做出来的管理制度“合用”呢?”。 由此我无比感叹那些为了“ISO认证”和“CMMI认证”的企业,只知其一,不知其二,没有找到真正的症结。

软件工程是实践中摸索出来的方法论。每个组织的大小、行业、具体情况都很不一样,更不谈人员组成、企业文化、客户的不同了。这样每个组织都应该找到适合自己发展的软件工程的方法和过程。软件项目需要在时间、资源和功能中找到平衡,如果一个目标本身都是有问题的,软件项目注定着会走向失败。而如果项目进度和工作量评估不靠谱的话,就更是雪上加霜了。目前公司的项目都或多或少的存在着这样的问题,然而我们真的学会了“折中”吗?我们继要应对快速的变化,又需要保证系统的安全可靠和高可用性。这是我们现阶段最需要解决的难题,体制问题和认得问题真的很难严格划分。

OOA和OOD仍然是软件工程根本,OOAD的能力以及每个程序员的立身之本。摈弃对流行语言的追捧,真正去实考OOAD的本质,才是现阶段很多开发人员需要做的(当然包括我)。DDD也只是OOAD中的其中一只罢了。

先学会“Think”(IBM),再去“Think different”(APPLE)!

Share and Enjoy:
  • Digg
  • del.icio.us
  • Facebook
  • LinkedIn
  • description
  • TwitThis
  • MySpace
  • StumbleUpon
  • Google
  • FriendFeed
  • Mixx
  • Reddit

Posted in 读书笔记. Tagged with .

单元测试HelloWorld

本文通过一个简单的例子说明单元测试的基本方法和jmock的基本技巧。JMOCK的使用请参考JMock使用FAQ,和JMock cookbook.

根据定义单元测试是开发者编写的一小段代码,用于检验被测代码的一个很小的、很明确的功能是否正确。所以我们首先来看看需要测试的类和其接口。

step 1 了解被测试代码

被测试类为HelloUnitTestServiceImpl ,它实现了IHelloUnitTestService接口。接口代码如下:


public interface IHelloUnitTestService {
public Object sayHelloToUnitTest(Object argument1,Object argument2);
}

实现类代码如下:


public class HelloUnitTestServiceImpl implements IHelloUnitTestService {
IFirstDependency  firstDependencyObj;
ISecondDependency secondDepedencyObj;

/**
* 需要被测试的方法。该方法有连个参数。实现中依赖到两个对象firstDependencyObj和secondDepedencyObj
*
*/
public Object sayHelloToUnitTest(Object argument1, Object argument2) {
if (argument1 == null) {
throw new IllegalArgumentException("第一个参数不能为空,否则报错");
}

//通过第一个依赖的对象对第一个参数进行运算
Object theFirstResult = firstDependencyObj.doSomeThingWith(argument1);
//通过第二个依赖的对象对第二个参数进行运算
Object theSecondResult = secondDepedencyObj.doSomeOtherThingWith(argument2);
//通过自己的私有方法对两个运算结果进行处理
Object sayHelloResult = doSomeThingPrivately(theFirstResult, theSecondResult);

//返回结果
if (sayHelloResult instanceof String)
return sayHelloResult;
else
return "结果不是String,所以我来代替!";
}

/**
* 该是私有方法对两个参数进行简单的toString相加的运算
* @param theFirstResult
* @param theSecondResult
* @return
*/
private Object doSomeThingPrivately(Object theFirstResult, Object theSecondResult) {
Object result = "Hello, " + theFirstResult.toString() +" "+ theSecondResult.toString()+"!";
return result;
}   //省略setter方法

值得说明的是,实现类需要通过两个依赖的类来处理sayHelloToUnitTest()方法的逻辑。即:


IFirstDependency  firstDependencyObj;
ISecondDependency secondDepedencyObj;

对于基于spring框架的应用来说,我们知道这两个依赖项,将会被spring容器通过setter方法注入到HelloUnitTestServiceImpl类。

step 2 创建JUnit测试用例

首先我们通过eclipse中的Junit的向导,新建一个JunitTestCase。

Wizard

在弹出的向导中设置好配置项。

请选择”New JUnit 3 test”

Wizard2

在Source folder中请通过”Browse”按钮选择源代码的文件夹。如:java.test, src/java/test等。

Wizard3

单击下一步后,选中需要测试的方法或者”单元”。

Wizard4

单击”Finish”按钮后,eclipse就将为我们生成单元测试用例类了。

step 3 编写单元测试用例代码

首先需要声明被测试类,以及JMock的context对象Mockery。

然后在setUp方法中对helloUnitTestService和context进行初始化。

注意,setUp方法继承与Junit框架中的TestCase基类。setUp方法是用来在多个测试方法运行过程中进行初始化,和数据准备之类的一个生命周期方法。

setUp-test-tearDown

如果不是很清楚,可以学习JUnit的Tutorial,网上有很多这样的教程。

所以setUp方法可以写成这样:


@Override
protected void setUp() throws Exception {
super.setUp();
context = new Mockery();
helloUnitTestService = new HelloUnitTestServiceImpl();
}

对于本例来说被测试的方法为sayHelloToUnitTest,它的正常运行决定与两个方面:

  1. 两个依赖项必须被正确的注入,否则将抛出空指针异常。在单元测试过程中为了测试的速度和性能,以及测试的粒度等诸多原因不可能使用spring容器的方式注入(有疑问可以和我沟通)。
  2. 两个传入参数必须满足测试用例的需要,即两个入参必须正确的配置并能模拟真实情况下代码被执行的路劲。

基于以上两点,我们的对策是。

  1. 对于两个依赖项,我们采用JMock的框架来模拟mock对象。即按照mock的思想将需要的依赖项进行mock,得到mock对象,然后通过setter方法注入到被测试对象中,就可以进行JUnit的断言了。JMock的使用请通过JMock的相关资料进行学习,如JMock的 tutorial和JMock使用FAQ等。
  2. 对与传入的两个参数,我们进行手动的模拟。如:new出对象,并进行set设值。

完成上面两步后,我们还需要对mock的依赖项的行为进行模拟(或者设置期望)。我们知道mock出来的对象虽然可被成功的以setter的方式注入,但是mock对象的行为还是未被正确设置,此时若运行测试,只会意外中断。我们可以这样来看,当sayHelloToUnitTest运行时,当运行到firstDependencyObj.doSomeThingWith(argument1)的时候,由于firstDependencyObj对象(即mock对象)并不知道doSomeThingWith该如何处理,或者如何返回期望的返回值。所以测试将被迫在此中断,并会抛出JMock的异常来。

所以sayHelloToUnitTest方法做为被测试方法,在执行过程中对它需要调用的依赖对象的方法(firstDependencyObj.doSomeThingWith(argument1))需要通过JMock的设置期望的方式模拟行为。设置的方法为:


//设置期望
context.checking(new Expectations() {
{
allowing(firstDependencyObj).doSomeThingWith(argument1);
will(returnValue("I Love Beijing"));
allowing(secondDepedencyObj).doSomeOtherThingWith(argument2);
will(returnValue("Tiananmen Square"));
}
});

这里我们设置firstDependencyObj的doSomeThingWith放在遇到argument1( 假定argument1 = “我爱北京”;)参数时,将返回”I Love Beijing”。同样的方法我们设置secondDepedencyObj的doSomeOtherThingWith在argument2时的返回值。

最后测试用例的代码如下:


public class HelloUnitTestServiceImplTest extends TestCase {

public Mockery                  context;
public HelloUnitTestServiceImpl helloUnitTestService;

@Override
protected void setUp() throws Exception {
super.setUp();
context = new Mockery();
helloUnitTestService = new HelloUnitTestServiceImpl();
}

public void testSayHelloToUnitTestTest() {
//准备参数
final Object argument1 = "我爱北京";
final Object argument2 = "天安门";
//mock依赖
final IFirstDependency firstDependencyObj = context.mock(IFirstDependency.class);
final ISecondDependency secondDepedencyObj = context.mock(ISecondDependency.class);

//设置期望
context.checking(new Expectations() {
{
allowing(firstDependencyObj).doSomeThingWith(argument1);
will(returnValue("I Love Beijing"));
allowing(secondDepedencyObj).doSomeOtherThingWith(argument2);
will(returnValue("Tiananmen Square"));
}
});

//依赖注入mock对象
helloUnitTestService.setFirstDependencyObj(firstDependencyObj);
helloUnitTestService.setSecondDepedencyObj(secondDepedencyObj);

//调用被测试的方法
Object actualSayHelloResult = helloUnitTestService.sayHelloToUnitTest(argument1, argument2);

//验证返回值是否为预期
Object expectedSayHelloResult = "Hello, I Love Beijing Tiananmen Square!";
assertEquals(expectedSayHelloResult, actualSayHelloResult);

//验证mock对象的行为是否为期望
context.assertIsSatisfied();
}
step 4 执行用例

通过eclipse向导我们就可以方便的运行用例进行测试并得到测试结果。

run-junit

此外还可以通过antx test以及 mvn test等方法运行一组测试,以及获取代码覆盖率的报告。

step 5 其他说明
  • 若该方法有多个分支,可以在这个测试用例类中增加其他测试分支的方法。如通过 testSayHelloToUnitTestTestWhileDependencyThrowsException的方法名,重新编写代码来测试依赖项抛出异常情况下的逻辑分支。PS:抛出异常可以通过JMock来模拟出来。
  • 对于没有依赖关系的方法,可不使用JMock。
  • 正确了解被测试类,被测试方法的逻辑是书写单元测试用例代码的关键。
  • JUnit的使用,如何断言,以及JMock的使用技巧等可以通过网络途径来学习。
小结

本文通过一个简单例子展示了Junit测试用例的创建方法,以及JMock框架的基本使用方法,意在指引读者对单元测试有一个初步认识。单元测试在实际执行过程中还有很多经验和技巧需要学习和掌握的,希望此文能够抛砖引玉,吸引读者不断学习和掌握单元测试相关的技巧。

Share and Enjoy:
  • Digg
  • del.icio.us
  • Facebook
  • LinkedIn
  • description
  • TwitThis
  • MySpace
  • StumbleUpon
  • Google
  • FriendFeed
  • Mixx
  • Reddit

Posted in 全部, 开发技术. Tagged with .

Test Double 分类


• A Dummy Object is a placeholder object that is passed to

the SUT as an argument (or an attribute of an argument) but is never

actually used.

作为对象参数的替身传给SUT,通常没有任何实际作用。

• A Test Stub is an object that replaces a real component on which the

SUT depends so that the test can control the indirect inputs of the SUT.

It allows the test to force the SUT down paths it might not otherwise

exercise.简言之,Test Stub可以控制间接输入,从而保证测试代码SUT的执行路径。

此外:子模式Responder injects valid values, Saboteur injects errors or exceptions

• A Test Spy, which is a more capable version of a Test Stub,

can be used to verify the indirect outputs of the SUT by giving the test a

way to inspect them after exercising the SUT.

Test Spy可以说成是有记录功能的Test Stub

• A Mock Object is an object that replaces a real component on which

the SUT depends so that the test can verify its indirect outputs。

和test Stub 不同的是,Mock object主要用来验证间接输出。

• A Fake Object (page 551) (or just "Fake" for short) is an object that

replaces the functionality of the real DOC with an alternative implementation

of the same functionality.

即对功能的简单实现,替换DOC。通常情况下使用Fake Object是因为测试DOC无法获取、太慢或者有副作用。

Share and Enjoy:
  • Digg
  • del.icio.us
  • Facebook
  • LinkedIn
  • description
  • TwitThis
  • MySpace
  • StumbleUpon
  • Google
  • FriendFeed
  • Mixx
  • Reddit

Posted in 全部, 读书笔记. Tagged with .

Test Utility Method Location

TestUtilityMethodLocation

  
由图可知,测试工具方法的位置主要有三个地方:

1. SuperClass,测试父类,通过继承来访问测试工具方法。

2. TestClass,放到测试类自身中,通过this的形式访问 。

3. TestHelper,放到测试帮助类中,通过delegate的形式访问。

Share and Enjoy:
  • Digg
  • del.icio.us
  • Facebook
  • LinkedIn
  • description
  • TwitThis
  • MySpace
  • StumbleUpon
  • Google
  • FriendFeed
  • Mixx
  • Reddit

Posted in 全部, 开发技术, 读书笔记. Tagged with .