public static junit.framework.Test suite() {

        return new junit.framework.JUnit4TestAdapter(SimpleTest.class);

}

l Tests can use the objects (variables) in a test fixture, with each test invoking different methods on objects in the fixture and asserting different expected results. Each test runs in its own test fixture to isolate tests from the changes made by other tests. That is, tests don't share the state of objects in the test fixture. Because the tests are isolated, they can be run in any order.

l A related issue is to design for testing. For example, if you have a method that is meant to output to a file, don't pass in a filename, or even a FileWriter. Instead, pass in a Writer. That way you can pass in a StringWriter to capture the output for testing purposes. Then you can add a method (e.g. writeToFileNamed(String filename)) to encapsulate the FileWriter creation.

l How do I test things that must be run in a J2EE container (e.g. servlets, EJBs)?

Refactoring J2EE components to delegate functionality to other objects that don't have to be run in a J2EE container will improve the design and testability of the software.

Cactus is an open source JUnit extension that can be used to test J2EE components in their natural environment.

l How do I run JUnit using Ant?

1.         Define any necessary Ant properties:

<property name="src" value="./src" />

<property name="lib" value="./lib" />

<property name="classes" value="./classes" />

<property name="test.class.name" value="com.xyz.MyTestSuite" />

2.         Set up the CLASSPATH to be used by JUnit:

<path id="test.classpath">

<pathelement location="${classes}" />

<pathelement location="/path/to/junit.jar" />

<fileset dir="${lib}">

    <include name="**/*.jar"/>

</fileset>

</path>

3.         Define the Ant task for running JUnit:

<target name="test">

<junit fork="yes" haltonfailure="yes">

    <test name="${test.class.name}" />

    <formatter type="plain" usefile="false" />

    <classpath refid="test.classpath" />

</junit>

</target>

4.         Run the test:

ant test

l How do I use Ant to create HTML test reports?

1.         Ensure that Ant's optional.jar file is either in your CLASSPATH or exists in your $ANT_HOME/lib directory.

2.         Add an ANT property for the directory containing the HTML reports:

<property name="test.reports" value="./reports" />

3.         Define the Ant task for running JUnit and generating reports:

<target name="test-html">

<junit fork="yes" printsummary="no" haltonfailure="no">

    <batchtest fork="yes" todir="${test.reports}" >

      <fileset dir="${classes}">

        <include name="**/*Test.class" />

      </fileset>

    </batchtest>

    <formatter type="xml" />

    <classpath refid="test.classpath" />

</junit>

<junitreport todir="${test.reports}">

    <fileset dir="${test.reports}">

      <include name="TEST-*.xml" />

    </fileset>

    <report todir="${test.reports}" />

</junitreport>

</target>

4.         Run the test:

ant test-html

l How do I organize all test classes in a TestSuite automatically and not use or manage a TestSuite explicitly?

There are a number of ways to do this:

1.         In Ant, use the junit task and the batchtest element:

<junit printsummary="yes" haltonfailure="yes">

...

<batchtest fork="yes">

    <fileset dir="${src.dir}">

       <include name="**/*Test.java" />

       <include name="**/Test*.java" />

    </fileset>

</batchtest>

</junit>

Idiomatic naming patterns for unit tests are Test*.java and *Test.java. Documentation and examples are at http://ant.apache.org/manual/OptionalTasks/junit.html.

2.         Use the DirectorySuiteBuilder and ArchiveSuiteBuilder (for jar/zip files) classes provided by JUnit-addons project:

DirectorySuiteBuilder builder = new DirectorySuiteBuilder();

builder.setSuffix("Test");

Test suite = builer.suite("/home/project/myproject/tests");

         Documentation and examples are at http://junit-addons.sourceforge.net.

3.         Write your own custom suite builder.

Have your test classes implement an interface and write a treewalker to load each class in a directory, inspect the class, and add any classes that implement the interface to a TestSuite.

You might only want to do this if you are very uncomfortable with using a naming convention for test classes. Aside from being slow for larger suites, ultimately it's arguable whether it's more effort to follow a naming convention that have test classes implement an interface!

Kent Beck, Erich Gamma

Simple Test Case

When you need to test something, here is what you do:

1. Annotate a method with @org.junit.Test
2. When you want to check a value, import org.junit.Assert.* statically, call assertTrue() and pass a boolean that is true if the test succeeds

@Test public void simpleAdd() {
      Money m12CHF= new Money(12, "CHF"); 
      Money m14CHF= new Money(14, "CHF"); 
      Money expected= new Money(26, "CHF"); 
      Money result= m12CHF.add(m14CHF); 
      assertTrue(expected.equals(result));
}

Fixture

When you have a common fixture, here is what you do:

1. Add a field for each part of the fixture
2. Annotate a method with @org.junit.Before and initialize the variables in that method
3. Annotate a method with @org.junit.After to release any permanent resources you allocated in setUp

public class MoneyTest { 
      private Money f12CHF; 
      private Money f14CHF; 
      private Money f28USD; 
      
      @Before public void setUp() { 
          f12CHF= new Money(12, "CHF"); 
          f14CHF= new Money(14, "CHF"); 
          f28USD= new Money(28, "USD"); 
      }
}

Running Tests

run this from a Java program:

org.junit.runner.JUnitCore.runClasses(TestClass1.class, ...);

java org.junit.runner.JUnitCore TestClass1.class [...other test classes...]

You make your JUnit 4 test classes accessible to a TestRunner designed to work with earlier versions of JUnit, declare a static method suite that returns a test.

public static junit.framework.Test suite() { 
      return new JUnit4TestAdapter(Example.class); 
}

Expected Exceptions

Making sure the code behaves as expected in exceptional situations is part of the craft of programming too. For example:

new ArrayList<Object>().get(0); 

@Test(expected= IndexOutOfBoundsException.class) public void empty() { 
      new ArrayList<Object>().get(0); 
}

外部工具的输出显示在控制台视图中。

在配置外部工具时可使用如下变量：
${workspace_loc}：
workspace的绝对路径

${workspace_loc:<resource path>}：
所指定的resource的绝对路径。resource path是相对于workspace root的完整路径。
注意：${workspace_loc:/myproject/myfile.txt}和${workspace_loc}/myproject/myfile.txt不一定相同，因为前者表示的myfile.txt可能位于workspace之外。

${project_loc}：
当前所选择的resource所在的project或正构建的project或所选择的的绝对路径

${project_loc:<resource path>}：
所指定的resource所在的project的绝对路径。resource path是相对于workspace root的相对路径。

${project_path}
当前选择的资源所在的project或者正构建的project的相对于workspace root的相对路径。

${project_name}
当前选择的资源所在的project或者正构建的project的名称

${container_loc}：
当前所选择的资源的parent的绝对路径

${container_loc:<resource path>}
所指定的resource的parent的绝对路径

${resource_loc}
当前选定的资源的绝对路径

${resource_loc:<resource path>}
所指定的资源的绝对路径

${container_path}
当前选定的资源的parent的相对于workspace root的路径

${resource_path}
当前选定的资源的相对于workspace root的路径

${container_name}
当前选定的资源的parent的名称

${resource_name}
当前选定的资源的名称

${build_type}
在外部工具作为构建的一部分时表示构建的类型。值可以是“full”、“incremental”、“auto”。如果外部工具运行于构建之外，值为“none”

假设workspace目录为c:\eclipse\workspace。
有两个project：MyProject1和MyProject2。
MyProject1位于workspace之内。
MyProject2位于workspace目录之外：c:\projects\MyProject2。
选中资源/MyProject2/MyFolder/MyFile.txt，则运行外部工具时，各对应变量值如下：
Variable Examples        Expanded Results
${workspace_loc} c:\eclipse\workspace
${workspace_loc:/MyProject1/MyFile.txt} c:\eclipse\workspace\MyProject\MyFile.txt
${workspace_loc:/MyProject2/MyFile.txt} c:\projects\MyProject2\MyFile.txt
${project_loc} c:\projects\MyProject2
${project_loc:/MyProject1/MyFile.txt} c:\eclipse\workspace\MyProject
${container_loc} c:\projects\MyProject2\MyFolder
${resource_loc} c:\projects\MyProject2\MyFile.txt
${project_path} /MyProject2
${container_path} /MyProject2/MyFolder
${resource_path} /MyProject2/MyFolder/MyFile.txt
${project_name} MyProject2
${container_name} MyFolder
${resource_name} MyFile.txt
${build_type} none

Using GMF, you can produce graphical editors for Eclipse. For example, a UML modeling tool, workflow editor, etc. Basically, a graphical editing surface for any domain model in EMF you'd like. For some example eyecandy, visit the gallery.

How can I get started using GMF?

For the tooling side, the tutorial is a good place to start. For the runtime, which can be used without the tooling, an article posted here is a good place to get an overview. For more information, take a look at the documentation available on the documentation site.

What are the advantages of using GMF over just EMF and GEF?

This depends on what you are trying to accomplish. For full-featured graphical editors that require the rich capabilities of GEF working with an EMF domain model, GMF is a good option. But then, you may be interested in a lightweight implementation, read-only visualizations, etc. In fact, you may not even need GEF, as is the case with TPTP's visualization of profiling data. For an overview of the features and functionality you can achieve using GMF, look here. To get a sense of how the generative framework can get you going quicker, look here.

What are the prerequisites for using GMF?

If you look at the download page for a particular build, you will see a list of prerequisites with links to their download pages. The update site contains stable (milestone) builds and will require their corresponding milestone releases from the main GMF dependencies (EMF and GEF).

What is the relationship between semantic, domain, notation, and graphical definition models?

In general, the terms semantic and domain model are synonymous and refer to the information being visualized and edited. The information used to represent and persist the visual elements in the GMF runtime is referred to as the notation model. When defining the diagram nodes and figures for use in generating the graphical editor, the toolsmith works with a graphical definition model. This is similar to the notation model, but they are distinct. The graphical definition model is linked to the domain and tooling definition models using a mapping model, which is used to produce a generation model that is used to drive the code generation. Clear as mud? ;) A picture of the models and their workflow is found at the beginning of the tutorial.

How can I contribute to GMF?

The best place to start is by looking in Bugzilla. Either find a bug to work on, coordinating with a developer, or submit a patch for an enhancement. Participation in the newsgroup and mailing list is also encouraged, as is trying out builds and reporting bugs, feature requests, documentation, etc.

What is the release plan for GMF?

You can find our project plan posted here.

在基于结构化数据模型(structured data model)构建工具和应用程序时，EMF可以充当模型框架(modeling framework)和代码生成工具(两种角色)。

从以XMI（XML Meta Interchange、基于XML的元数据交换）描述的model中，EMF能够生成model对应的类和一些适配类(adapter class)。model类用于代表模型本身；适配类能够查看和以命令的方式编辑model，并提供了一个基本的editor。

EMF构建包里面包括XML Schema Infoset Model（XSD）和一个基于EMF的Service Data Objects（SDO）实现。XSD现在已经是另外一个Eclipse项目Model Development Tools（MDT）的组成部分。XSD提供了处理XML Schema的模型和API。

EMF的子项目还包括：
Model Query：查询Model的元素和内容
Model Transaction：构建于EMF之上，为管理EMF资源提供管理层模型
Validation Framework：保证model的完整性

EMF有三个组成部分：
EMF：
核心的EMF框架，meta model(Ecore).
提供对model的支持，包括变化通知、持久化支持(默认的XMI方式)、处理EMF对象的API等
EMF.Edit：
包括为EMF model创建editor所需要的可重用类
a)content provier and label provider、property source support、其它显示EMF model在桌面上的工具类
b)command framework。包括完全支持redo undo操作的command实现类。
EMF.Codegen：
能生成构建一个完全的EMF Model Editor所需的一切资源。
含有一个可指定生成命令和选择生成器的图形界面。
代码生成利用了Eclipse JDT（Java Development Tooling）

代码生成包括三个级别：
1. Model
提供model中所有class和interface的实现类，加上factory和package（meta data）实现类
2. Adapters
生成用于编辑和显示model class的实现类，这些实现类成为ItemProviders
3. Editors
生成正确的结构化的Editor

在Oracle改进自己产品的过程中，Koch System的研究成果也为这些改进做出了贡献。产品的进步，来源于许多方面，产品实施人员、销售人员、最终用户，都能为产品的改进做出贡献。收集反馈意见。

The Complete Reference这本书构思与1988年。旧金山的一个知名出版代理商很欣赏George的想法，签订了出版合同，并计划于89年出第一版。但他们的一个高级主管否定了这个计划，因为他认为oracle仅会昙花一现。一年后，Oracle成倍增长，该主管也离职了，于是这个出版计划又重新启动，最终90年发布第一版。当达到一定水平之后，搭上出版社会是很容易的事情。虽然不出名的时候也能出书，但那仅能被视为侥幸。也不要因别人的侥幸而愤愤不平，把侥幸变为必然。

90年7月，George就职于Oracle公司，管理其Application部门。并在后来当上了公司的高级副总裁。在他任职期间，他把那个出版社又介绍给了oracle的高级管理层，在抵制住一位Oracle副总裁(不久离职)的反对后，成立了Oracle出版社。

92年，Bob Muller修订了这本书，产生了《Oracle 7：The Complete Reference》。

94年，George成就了自己的梦想，当上了一名专职牧师。这是达到一定高度之后，才能获得的自由。

94年，Kevin Loney，一个极知名的独立的Oracle顾问兼作者(www.kevinloney.com)修改和重写了第三版。出技术之外，知名度的优势在这儿得到了体现。George称，Kevin的才智和勤奋给他留下的深刻的印象。才智！勤奋！！！

不必有什么逻辑、不必有什么条理、也不必追求什么完整性，只要大约记录我每天干了什么就OK了，先做到这一步吧。

今天订了本《如何掌控自己的时间和生活》，对它抱有挺大的期望，希望真的象所说的那样：这个世界上根本不存在“没时间”这回事，舒缓一下忙的有些焦头烂额然后无头乱窜的现在的我。

----------------------------------------------------------------------------------------------------

看着自家牛死而伤心落泪的老农，假若阴错阳差坐了龙庭，没准比朱元璋杀人还疯狂。

拉米多说：“首先要在他们的心里装上一把锁，然后才能让他们主动来购买咱们的防盗门和防盗锁。他们心里那把锁的名字就叫贪欲。开始时，他们之所以能和平共处，是因为他们都不缺少食物，但是后来，当他们发现每人所得的食物分量不同时，便有了不愿与他人分享的想法了。这便是我多给一部分人羊肉，和少给一部分人羊肉的效果。”

从赞扬和真诚赏识他人开始。（要由衷）

即使最小的改进，也要表扬；每有改进，都要表扬。“赞赏要由衷，表扬要慷慨。”

给他人一个好名声，使其与之相配。(这种名声，会是鞭策他前进的动力之一)

----------------------------------------------------------------------------------------------

原来可以这样拼

一个月前，老师布置了拼图作业。今天，孩子们带来了自己的作品。老师请大家谈谈拼图作业的体会和感受。

学生：我拼图的时候，先看一下包装上的图画，心中有一个轮廓，然后把外框拼好，再从外向内，这种方法拼得比较快。老师：很好。认识一个问题从总的概貌入手，然后去了解细节，就像我们面对一个陌生的城市，用一张地图，比一条街一条街去走要快得多。

学生：我拼了很长时间也拼不好，所以请爸爸妈妈和奶奶帮忙完成了拼图。老师：很好。这是一种teamwork（团队合作），记住：如果你遇到自己一个人难以解决的问题，可以求助别人，大家共同完成。

学生：我最高兴的时刻是把最后一片放进拼图的时候。老师：很好。享受成功是一种非常愉悦的感觉。

学生：我面前是一大堆杂乱不章的拼图片，我根本找不出它们的规律，我试了很多次也无法拼出图案，我心情很急躁、烦闷，干脆把它装起来，再也没有打开。老师：很好。有时放弃也是一种选择。

OO软件系统设计的核心问题：
可维护性（Maintainability）
可复用性 （Reuseability）

3.1 软件系统的可维护性
开发半年，维护多年
一个软件系统生命周期内，维护上面的钱，是开发上的钱的两倍

软件的维护
维护的含义：错误的清除、功能的扩充

好的软件设计必须允许新需求以容易和平稳的方式加入到已有系统中

一个软件生命周期内，常因为小改动的累计导致系统臃肿

设计师的辩解
常见辩解：用户需求变化无常。维护设计师和原始设计师不同时，理由更多。

首先，设计未必适合扩充；再者，即使适合扩充，维护设计师未必能理解原始设计师意图。

真正的原因
Rober C. Martin指出真正原因：
1) 过于僵硬
因新性能会波及多个模块而不敢轻易加入新功能
2) 过于脆弱
一个地方修改，可能导致未知地方发生错误
3) 复用率低
已有代码依赖于一堆东西，难以拆开
最原始的服用方式：代码拷贝粘贴
4) 黏度过高
两种方式：以保存原始设计意图和原始设计框架的方式改动；破坏原始意图和框架的方式改动。涉及到短期利益和中长期利益的问题。如果总是第二种方式比第一种方式方便，就是黏度过高

设计的目标
Peter Coad提出
1) 可扩展性
新新能很容易加入到系统中去
2) 灵活性
允许代码修改以很平稳的方式进行，不会涉及很多模块
3) 可插入性
很容易把一个类抽取，用一个同样接口的类替换

3.2 系统的可复用性

复用的重要性
好处：
1) 较高的生产效率
2) 较高的软件质量
3) 可改善系统可维护性

传统的复用方式
代码拷贝粘贴、算法的复用、数据结构的复用

可维护性和复用性有时会发生冲突，想要的：支持可维护性的复用

面向对象设计的复用
复用焦点的转移：不在集中在函数和算法等具体实现细节上，而是集中在含有商业逻辑的抽象层次上。
在面向对象的设计里面，可维护性复用是以设计原则和设计模式为基础的。

常见OO设计原则
开闭原则
里氏代换原则
依赖倒转原则
接口隔离原则
组合/聚合原则
迪米特法则

1. 黑盒测试模式(black box testing)
也称为功能测试(functional testing)、闭箱测试(closed box testing)。

通过设计符合独立需求的测试来保证软件符合要求，测试不必基于所实现的方式。

从某种意义上讲，不按照软件实现或者内在结构进行的软件测试称为黑盒测试。

2. 白盒测试模式
也称为明箱测试(clear box testing)

根据软件的内部结构来确定必要情况。一个完整的测试将测试软件所有可能经过的路径。

但并不真正的需要测试所有条件，可以根据软件的内部结构来决定哪些测试是必须的和有意义的。

注意：
² 需保证软件在所有情况下的正确实现
² 最低限度的测试集合必须满足下面的条件：确保软件在所有的条件下实现，并且自始至终覆盖软件实现的所有可能路径。
² 仔细分析与每条实现路径相关的边界条件(boundary condition)，有利于减少测试数目。

一些通用的边界条件：
² 导致一个数字数据类型发生溢出的值
² 导致一个数据结构发生溢出的值
² 导致布尔表达式在一个if条件可能为真或为假时的值

为了确保能够测试所有软件经过的路径，采用一个覆盖分析(coverage analysis)工具保存已经测试过的路径轨迹。

白盒测试的成本可能会非常高。

3. 单元测试模式
将程序中的一个单独的类从其它类中隔离出来进行测试。

一个类的完整单元测试可以改善它的可重用性(reusability)。

如果一个将要进行单元测试的类与另外一个类相互依存，并且创建另一类的虚拟版本不太显示，单元测试可以考虑将这两个类一起进行测试。

4. 集合测试模式
首次将单独开发好的类集合到一起进行的测试。

每个类进行了单元测试，第一次把他们组装到一起，并检验工作协调性的过程称为集成测试(integration testing)。

在开始时，先将少量的一些类集合到一起进行测试，然后再不断将一些类加入来进行测试，通过这种方法可以将集合测试的杂乱程度降到最低。

设计一个集合测试计划时，首先应道确定一个用于组织测试的程序结构。通用方法是：
² 以自上而下或者自下而上的模式组织类，或者同时采用这两种模式组合类。这种技术易于理解，但是应用于面向对象设计时可能会困难，因为大多数面向对象设计层次性不强。
² 将与一个通用程序特征相关的众多类合并到一起，或者使用案例
² 将与一个公共线程相关的类合并到一起。

对于小型或中型工程的集合测试来说，常很少要求为它们做测试规划，大型工程的集合测试需要相对正规的规划。

集合测试常比系统测试所花的时间少，比单元测试所花的时间多。

5. 系统测试模式
把程序当成是一个完整的实体，在一个与它运行的环境相似的环境中测试，确保它符合规范。

6. 回归测试模式

7. 验收测试模式(Acceptance Testing)
验收测试是为了确保发布的软件符合用户的需求。这种测试常由用户实现。

软件开发人员希望新开发的定制软件可以满足用户的需求，但是有些需求是用户从来没有向开发人员表述过的。

验收软件的手续必须面对实际，因为开发者无法决定用户用何种办法验收该软件。比如“屏幕要求美观”的测试会带有很多的主观因素，而验收一个程序的屏幕是否符合编写规范的要求会显得比较合适一些。

解决方案：
在开发者开始工程设计之前，经过讨论，在验收测试计划方面产生共识。

一个验收计划应包括下面的元素：
² 应包括一个指明验收测试范围的声明。如软件组件、操作环境或硬件。也可以明确验收测试的高级目标。一些经典的目标包括：
ü 新系统产生的结果应与现存系统产生的结果相同
ü 新软件必须具备没秒钟处理相当数量事务的工作能力
ü 必须采用一个最低级别精确度来实现计算
² 应当声明用于验收测试的测试数据。如可能，数据应当符合实际产品的数据
² 指出谁将负责开发必要的详细测试计划、测试环境和技术支持
² 还应说明谁来确保软件通过验收测试

负责验收测试的人员很自然的趋向于对将要测试的软件持怀疑态度。他们宁愿承认是软件缺陷导致出错也不愿承认是因为对软件的不熟悉而导致出错。
可预先做一些工作使验收测试人员熟悉软件。

制定验收测试计划可能需要一些时间，但是这时还处于测试的开始阶段，成员之间没有过多的争论，还心平气和，便于测试人员和开发人员讨论尚未达成的共识。

8. 静室测试模式
软件的设计人员和软件测试的人员不应当讨论他们的设计规范或实现过程。

软件开发和测试开发都同样受详细规范的约束。如果测试设计人员和软件设计人员采用相同的方式描述规范，那么测试将无法发现那些不确定的东西。

采用静室测试模式相互不会被对方引诱到规范中不确定的部分中。不过有可能在发现问题的测试进行之前，不容易发现某些规范的不确定部分。