The kgenprog from kusumotolab

--root-dir オプションを追加したにも関わらず，rootDir を使用していない．
@Deprecated な rootDir を指定しない TargetProject のコンストラクタを呼び出している.

適切なコンストラクタを呼び出す
適切なテストも追加

GA の変異処理実装

題材プロジェクトの説明を追加

example/README.mdに一覧を書く？

対象プロジェクトのビルド

プロジェクトビルド時に古いクラスファイルが残ったままになっている

AST の構築

SourceFileに子クラスを作る

TargetSourceFileとTestSourceFileを作る．
ストロングな型でAPIを呼び出したい．

APR によって生成されたパッチの出力処理の実装

JUnit の実行

ソースコードの「場所」をどう表現するかを検討

テスト派：FQN + 行番号
GA派：ファイルパス＋ASTノード

言葉がぜんぜん違う．どうあるべきか．
共通言語でできないか．

GA の評価処理実装

GeneratedJDTAST#getPrimaryClassNameの実装

stubが残っているので #86 でヌルポ．

// GeneratedJDTAST.java L31
@Override
public String getPrimaryClassName() {
  // TODO Auto-generated method stub
  return null;
}

担当者は arima/matsumoto どっち？
自分で割り振って作業してください

FQNにSourceFileフィールドを追加

FQNからSourceFile名への変換に必須．

ProjectBuilder.build()の中の処理として，FQNを生成しつつSourceFile名へのマッピングをメモしておく．

FullQualifiedNameに子クラスをつくる

TargetFQNとTestFQNを作る．
see #57

AST の書き換え処理実装

Slack への通知テスト

この issue がちゃんと通知されていればおｋ

TargetProjectの再検討

TargetProjectの持つべき要素が足りておらず，テスト実行で困っている．例えば，TargetProjectの中身が以下だとして，

sourceFiles: ["../example01/src/jp/kusu/X.java"]      //便宜上相対パスに．絶対パスでも可
testFiles:   ["../example01/src/jp/kusu/XTest.java"]

どこがプロジェクトのルート（../example01）で，どこがソースディレクトリ（src）か区別できない．テスト実行ではソースコードの限定名（jp.kusu.X）で処理するので，上記の区別が必須．

そもそも TargetProjectの情報 ∋ .classpathの情報 + .projectの情報 であるべき．よって最低限以下を追加すべき．

ルートディレクトリへのパス
ソースコードディレクトリへのパス（複数）
JUnitのバージョン

JUnitのバージョンはひとまずどうでも良い．各種パスをどう表現するを考えたい．TargetProjectは複数クラスに依存しており，さらにCLI（＝UI）を左右する要因になるので，きちんと考えるべき．

javaファイルセパレータの調査と検討

プラットフォームに依存しないセパレータの書き方（使い方）を考えるべき．
例えば，

String path1 = "src/jp/a.java";
String path2 = "src" + File.separator() + "jp" + File.separator() + "a.java";

この例だと，後者がプラットフォーム非依存だが視認性が低すぎる．
一方，前者はこういうケースで問題が起きる．

String path1 = "src/jp/a.java";
assertEquals(path1, new File(path1).toString()); // 第二引数側がOSによって変化する．winでfailする．

そもそもの問題は「生Stringを扱っている」という点．
あらゆるString型のpathは，FileやPath等のクラスにラップして使うという前提を満たせるのであれば，

File file1 = new File("src/jp/a.java");
File file2 = new File("src" + File.separator() + "jp" + File.separator() + "a.java");

どちらでも問題はない．むしろ前者が見やすい．

kgenprogにおいては，基本的にString型pathは生で使わずにSourceFileクラス等でラップして使う．
よってSourceFileクラスが / を解釈してくれるべき．

一般的にはどうするのが正解か？調べるべき．
コメント求む．

final TestExecutor executor = new TestExecutor(
  new URL[] { new URL("file:./example/example01/_bin/") }); // TODO

Location location = GeneratedSourceCode.solve(fqn, lineNumber);
// イメージ

- projectBuilder.build(outDirPath);
+ projectBuilder.build(targetProject.getInitialVariant());

TargetProject.SourceFiles = ["BuggyCalculator.java", "BuggyCalculatorTest.java"];
TargetProject.TestFiles   = ["BuggyCalculatorTest.java"];

こうあるべきでは．

TargetProject.SourceFiles = ["BuggyCalculator.java"]
TargetProject.TestFiles   = ["BuggyCalculatorTest.java"]

「TargetProjectのデータ構造がどうあるのが自然か」という議論．
影響はProjectBuilderとTestProcessBuilderの2つ．

main起動時のconfigの検討

main起動の方法が引数で渡すだけでなく，configでどかんと渡したい．

// 引数で実行
$ main -s example01/src/main/java/ -t example01/src/test/java ...
// configで実行
$ main --config kgenprog.conf

configの中身や書式は要検討．

BuildResultsの生成

BuildResultsにビルドの結果を保持させる．

内部フィールド．

boolean isBuildFailed;
List<FQN> targetFqns;
List<FQN> testFqns;
Path outDir;
List<Path> classFiles;

使い方

final BuildResults br = new ProjectBuilder(targetProject).build(outDir);

シンプル，素，依存が少なくビルドが容易
単体テストが用意されている
わかりやすいバグがある
そのバグがAPRで修正可能

build.gradle (gradle)
pom.xml (maven)
build.xml (ant)
.classpath & .project (eclipse)
.iml & .idea/ (intellij)

ProjectBuilderのテスト追加

テスト足したほうがよいですね．
Variantありビルドはともかく，初期ソースコードのビルド成否は確認すべき．

kusumotolab / kgenprog Goto Github PK

kgenprog's People

Contributors

Stargazers

Watchers

Forkers

kgenprog's Issues

Recommend Projects

Recommend Topics

Recommend Org