Groovyのテストケース作成ウィザード

Groovyでテストケース作成した場合正しくコード生成が行えないことがわかった。
doSample(),doString()メソッドがあるクラスのテストクラスを自動生成したが
testDoSample(),testDoStrin()メソッドがクラスの外部に生成されている。
そのため、エラーが発生する。

package sample.test;

import static org.junit.Assert.*;

import org.junit.After;
import org.junit.AfterClass;
import org.junit.Before;
import org.junit.BeforeClass;
import org.junit.Test;

class hoge {

@BeforeClass
public static void setUpBeforeClass() throws Exception {
}

@AfterClass
public static void tearDownAfterClass() throws Exception {
}

@Before
public void setUp() throws Exception {
}

@After
public void tearDown() throws Exception {
}

@Test
public final void testDoStringObject() {
fail("Not yet implemented"); // TODO
}
}

@Test
public final void testDoSample(){
fail("Not yet implemented"); // TODO
}

@Test
public final void testDoString(){
fail("Not yet implemented"); // TODO
}

antを勉強する

プロジェクトで開発を行うためには自動化が重要ということでantをマスターせねばということでantの本を買いました。
ant

開発に必要なプロジェクトをsubversionで更新を行う＆リフレッシュをするという仕組みを作る。
以下こんな感じでやるのがよいかもしれません。

EMFValidationの翻訳

使えるかと思うので翻訳をしてみました。
あとでちゃんと直します。


The validation framework provides support for constraint providers for any EMF meta-model (batch and live constraints), customizable model traversal algorithms, constraint parsing for languages, configurable constraint bindings to application contexts and validation listeners. The following are the main extension points and classes to be used with the validation framework.

ValidationFrameworkは以下のような制約プロバイダのサポートを提供する。
EMFメタモデル、モデルトラバーサルアルゴリズム、言語の制約パース、アプリケーションコンテキスト、validation リスナのバインディング制約などである。
次のようなvalidationFrameworkを使ったクラスや拡張ポイントがある。


1.The extension point org.eclipse.emf.validation.constraintProviders is used to provide constraints. Static constraint providers declare constraints in the plugin.xml. Constraints are grouped into hierarchically structured categories. Constraint providers target one or more EPackages by namespace URI. A group of constraints declares categories in which they are members. Each constraint has a variety of meta-data associated with it (Language, ID, severity, mode, name, message, triggers, etc.). Dynamic constraint providers address situations where constraints cannot be declared statically. e.g., where constraints are defined in models or other resources. Dynamic providers declare a class implementing the IModelConstraintProvider interface. This class is responsible for making constraints available on the appropriate triggers, organizing them into categories, etc.

拡張ポイントorg.eclipse.emf.validation.constraintProvidersで制約を与えることができる。
静的な制約はplugin.xmlで宣言をすることができる。
制約は構造化されたカテゴリに階層的にグループ化することができる。
制約プロバイダは１つのターゲットや名前空間URIのEPackageをターゲットにすることができる。
制約グループはメンバーのカテゴリを宣言する。
各々の制約はそれに関連するメタデータに種類を持つ。
（言語、ID,severity,mode,name,message,triggers)
次に動的な制約は静的に制約が定義できない場合に使われる。
制約はモデルや他のリソースで定義される。
動的な制約プロバイダはIModelConstraintProviderインタフェースを実装したクラスで
定義できる。
このクラスは適当なトリガや、カテゴリに組み込む制約を有用化する責任をおう。

2.The extension point org.eclipse.emf.validation.traversal is used to provide customizable model traversal algorithms. Batch validation traverses a subset of the model starting from the user's selections. No traversal is performed in live validation. Some meta-models require custom strategies for traversal. The default strategy simply iterates the content tree via eAllContents() API. Some meta-models do not use EMF containment relationships extensively, or implement logical models on multiple distinct resources, making containment-based traversal impractical.

拡張ポイントorg.eclipse.emf.validation.traversalはモデルトラバーサルなアルゴリズムで使用する。
バッチvalidationはユーザの選択したモデルのサブセットを横断する。
live validationはモデルの横断はできない。
トラバーサルには独自ロジックが必要となる。
デフォルトのロジックはeAllContents() APIを通してコンテンツツリーを走査する。
メタモデルはEMF Containment関係を使わない。
または、または多重の区別するリソースについてモデルや実用的なコンテナベースの横断を
持ったモデルを実装する。


3.The extension point org.eclipse.emf.validation.constraintParsers is used to provide constraint parsing for languages. The validation framework provides support for two languages: Java and OCL. Clients can provide support for other constraint languages via constraint parsers. The Language ID: used in the lang attribute of constraint elements in the constraint XML. The Class: identifies an implementation of the IXmlConstraintParser interface, which constructs a constraint from the XML configuration data. Constraint parsers are responsible for parsing the content of a constraint element in the plugin.xml to produce IModelConstraint objects.

拡張ポイントorg.eclipse.emf.validation.constraintParsersは言語の制約パースに対して使われる。
validation frameworkは2つの言語(Java OCL)で利用される。
クライアントは制約パーサを通して他の制約言語に対するサポートを提供できる。
言語ID：制約XMLの中の制約の要素の属性で使われる。
クラス：IXｍｌConstraintParserインタフェースで実装された識別
XMLの設定ファイルからの制約で作成された。
制約パーサはIModelConstraintを作るためのplugin.xmlに記述された
制約要素のコンテンツをパースするのに使われる。


4.The extension point org.eclipse.emf.validation.constraintBindings allows clients of the EMF Validation framework to define "client contexts" that describe the objects that they are interested in validating, and to bind them to constraints that they are interested in enforcing on these objects. A client context can declare an enablement expression that matches model elements that are included in the context. Where that is not sufficient, an alternative is to define a selector class using a selector element. Client contexts can be bound to constraints, individually, or to constraint categories (to bind all of the constraints in the category). Binding to constraint categories has the advantage of allowing new constraint contributions in a category to automatically be bound to the appropriate client context, even if the constraint is defined in a plug-in that is unaware of that context or its binding to the category. Category bindings are inherited by sub-categories from their ancestors.

拡張ポイントorg.eclipse.emf.validation.constraintBindingは
EMFValidationフレームワークのクライアントが"クライアントコンテキスト"を定義できる。
クライアントコンテキストはvalidationで興味があるオブジェクトを記述する。
オブジェクトに対して実施することに興味がある制約に対してバインドする。
クライアントコンテキストはコンテキストの中にあるモデル要素にマッチした可能な表現
で定義する。
十分でない場合、オルタネイティブはセレクタ要素を使ってセレクタクラスを定義すべきである。
クライアントコンテキストは制約や制約カテゴリ（カテゴリのすべての制約）に対してここに
バインディングできる。
制約カテゴリのバインディングはクライアントコンテキストを自動的にバインディングするため
カテゴリへの新しい制約の寄与の利点を持つ。
たとえ制約がコンテキストを意識せずにプラグインやカテゴリへのバインディングを定義できたとしても、
カテゴリバインディングは親からのサブカテゴリによって受け継がれる

5.The extension point org.eclipse.emf.validation.validationListeners is used to define validation listeners for the validation service (org.eclipse.emf.validation.service.ModelValidationService). The validation service will inform this listener whenever validation has occurred, loading it if necessary in order to do so. This is most useful for cases where client plug-ins need to find out about validation events even before they are loaded. Otherwise, it is usually simpler just to programmatically add a listener to the validation service. The value of the listener element class attribute must be the fully qualified name of a class that implements the IValidationListener interface. Listeners can also be registered in code, at run-time, using the ModelValidationService.addValidationListener() method.

拡張ポイント.org.eclipse.emf.validation.validationListenersは
validationサービスに対してvalidationリスナを定義するために利用する。
validationサービスはリスナにvalidationが起きたという情報を伝える。
もしそのようなことをするためには必要ならば、リスナをロードする。
これはクライアントプラグインがロードする前にvalidationイベントについて
理解する必要があるケースに使われる。
普通validationサービスに対してリスナをプログラム的に追加するのは簡単。
リスナ要素のクラス属性の値がLValidationListenerインタフェースを実装したクラス名を
制限されなければならない。
実行時はMdelValidationService.addValidationListerner()を使ってリスナは登録される。

6.The ModelValidationService singleton coordinates the invocation of validation. It defines a single factory method for creation of IValidator for the batch and live evaluation modes. Validators validate one or more objects at a time; the kind of object accepted as input depends on the evaluation mode. They can be configured to report constraint passes as well as failures, for verbose results. Results are reported as IValidationStatus. Validators can be reused by a client for any number of validation operations. The ILiveValidator validates EMF Notifications. The IBatchValidator validates EObjects and, due to its support for model traversal, supports progress monitors. Registered traversal strategies can be overridden by the client.

ModelValidationServiceはシングルトンでvalidationの実行を行う。
これはbatchモードliveモードに対してIValidatorを生成するファクトリメソッドを
定義する。
Validatorsは1つやそれ以上のオブジェクトをvalidateする。
評価モードに依存する入力として受けられたオブジェクトの種類。
それらは詳細な結果に対して制約の通過同様失敗のレポートすることを設定される。
結果はIValidationStatusとしてレポートされる。
Validatorはvalidation operationの数に対してクライアントは再利用する。
ILiveValidatorはEMF通知をvalidateする。
IBatchValidatorはEObjectをvalidateし、モデルトラバーサル、プログレスモニタ
をサポートする。
登録されたトラバーサルストラテジはクライアントでオーバーライドする。

7.Clients can create an EValidator implementation that delegates to the validation framework.

クライアントはvalidation frameworkを委譲したEValidator実装で作成される。


8.The framework provides implementation of an XML constraint parser (org.eclipse.emf.validation.xml.IXmlConstraintParser) API that supports definition of XML constraints in OCL. The class OclConstraintParser is the constraint parser implementation that creates instances of the OclModelConstraint class, the OCL-language constraint implementation, from XML constraint descriptors. It uses the Query class to test model elements against an OCL constraint expression.

frameworkはXML制約パーサAPIの実装を提供する。
(org.eclipse.emf.validation.xml.IXmlConstraintParser)
APIはOCLのXML制約を定義できる。
クラスOclCOntraintParserは制約パーサである。
OclModelConstraintクラスでインスタンス化された制約パース実装である。
OCL言語は制約を、実装する。
OCL制約表現に対してモデル要素のテストするためにクエリクラスを使う。