2016-01-14

typechecker-clientで型のカバレッジ取れるようにした

Hacklang HHVM Hack

f:id:holyshared:20160114113035p:plain

型チェックの比率が知りたかったので、クライントのライブラリにAPIを新しく追加しました。ファイル／ディレクトリ単位でデータを抜いて、整形することで見やすいフォーマットに整形して表示したり、データを別の形式に変換したりすることができます。

簡単な使用方法

基本的に非同期な処理なので、awaitを使用して計算が終わるまで待つ必要があります。
具体的なコードは次のような感じになります。

async function coverage_select_main(string $cwd) : Awaitable<void>
{
    $client = new TypeCheckerClient($cwd);
    await $client->restart();

    $result = await $client->coverage();
    $files = $result->filter(($file) ==> $file instanceof File)
        ->filter(($file) ==> preg_match('/typechecker-client\/src/', $file->name()) === 1);

    echo 'Files:', PHP_EOL;
    foreach ($files as $file) {
        $formattedParsentage = sprintf('%6.2f%%', (float) $file->parsentage() * 100);
        echo $formattedParsentage, ' ', $file->name(), PHP_EOL;
    }
}
coverage_select_main(realpath(__DIR__ . '/../'));

どうやっているのか

HHVMにはhh_clientというコマンドラインプログラムがあります。
こいつを使用すると、型のチェックとカバレッジ計算ができます。

hh_clientには–coverageオプションがあり、実行時に指定するだけで型チェックの比率を確認できます。

hh_client check --coverage [対象ディレクトリ]

また、追加で–jsonオプションを指定することで、チェック結果をjson形式で出力できます。

hh_client check --json --coverage [対象ディレクトリ]

typechecker-clientはこの出力されたjsonデータを使用しています。

リポジトリ

hhpackっていうorganizationで公開しているので、PRお待ちしております。

github.com

注意事項

HHVM 3.11.0で試す場合、hh_clientのバグで、プロセスが死なずに残る問題が発生しています。
これはもうすぐパッチがでるはずなので、しばらくまってください。

github.com

まあ、今月末くらいにLTSの3.12.0でるので、3.11.0のことなんてどうでもよくなると思います。

2015-12-01

typesafetyっていうパッケージを作った

Hacklang HHVM Hack

Screenshot

typesafetyというパッケージを作りました。
Hacklangでコードを書いていると頻繁に型のチェックをかけるのですが、チェックをするのにサーバーを再起動したりしないといけないのでとても面倒でした。
なので、サーバーの起動と型のチェックをまとめてできるようにしました。
特徴として、全てstrictモードで実装されているのと、UNSAFEコメントを使用したアンチパターンを使用していません。

使い方

composerを使用して、インストールします。

composer require hhpack/typesafety

後はコマンドを実行するだけで、型のチェックを行えます。

vendor/bin/typesafety [ROOT_DIRECTORY]

さらに、composer.jsonのscriptsに実行できるようにすると楽になります。

{
    "scripts": {
        "check": "vendor/bin/typesafety"
    }
}

これで下記のように簡単に型チェックを行えるようになります。

composer check

CIでの型チェック

CIでテスト実行前に、型チェックをかけることにより、型安全な状態でテストを実行することができます。
型の補償がされていない状態でテストを実行しても、正常に終了する確率が低いので、事前に型のチェックを行うことでテスト時間を短縮できます。

travis-ciの場合は、yamlの設定ファイルに型のチェックを追加することで、実現できます。

script:
  - composer check
  - composer test

typesafetyをリリースするのに別途作ったパッケージ

hhpack/process - プロセスを扱うパッケージ、サブプロセスでコマンドを実行できたりする
hhpack/typechecker-client - 型チェッカーのクライアントライブラリ、サーバーの起動、停止などで使用する
hhpack/color - コンソールの出力をカラーリングするのに使用
hhpack/publisher - シンプルなPub/Subライブラリ、型のチェック結果を通知するのに使用

2015-06-15

Hacklang用のテスティングフレームワークを作った件

Hacklang HHVM Test Hack

Screen Shot

hhspecifyっていうBDD styleのテスティングフレームワークを公開しました。下記のコマンドでcomposerを利用してインストールできます。

composer require hhspecify/hhspecify

使い方は下記の通り。

設定ファイルの作成

まず、最初に設定ファイルを作成します。
ファイル名はhhspecify.hhです。

configureメソッドにConfigBuilderを受け付ける、ラムダ式を指定します。今の所設定できるのが、パッケージとレポーターだけです。

<?hh //partial

use hhspecify\HHSpecify;
use hhspecify\config\ConfigBuilder;
use hhspecify\reporter\SpecificationReporter;

HHSpecify::configure((ConfigBuilder $builder) ==> {

    $package = shape(
        'namespace' => 'vendorname\\spec\\', //スペックファイルの名前空間
        'packageDirectory' => __DIR__ . '/spec' //スペックファイルのディレクトリ
    );

    $builder->package($package)
        ->featureReporter(new SpecificationReporter());

});

スペックファイルの作成

スペックファイルを置くディレクトリにスペックファイルを置きます。
ファイル名はなんでもOKです。

ここではStackSpecというファイル名にします。
implementsのインターフェース指定にSpecificationを指定します。

use hhspecify\Specification;
use hhspecify\feature\FeatureVerifierBuilder as Feature;

final class StackSpec implements Specification
{

    public function __construct(
        private Vector<int> $stack = Vector {}
    )
    {
    }

}

テストメソッドの記述

テストメソッドにFeature属性を指定します。
引数のFeatureVerifierBuilderのインスタンスを実行時に受け取るので、 setup/when/then/cleanupの順に検証コードを記述していきます。

setup - 初期処理のコードを記述する
when - テストをしたい処理をするコードを記述する
then - whenを実行した後の結果を検証するコードを記述する
cleanup - 後処理のコードを記述する

<<Feature("Vector::add")>>
public function add_value_to_vector(Feature $feature) : void
{
    //setup block - Setup
    $feature->setup(() ==> {
        $this->stack = Vector {}; //Vectorを初期化する
    });

    //when block - Stimulus
    $feature->when(() ==> {
        $this->stack->add(1); //値を追加する
    });

    //then block - Response
    $feature->then(() ==> {
        invariant($this->stack->count() === 1, 'must have been added value'); //値が追加されているか検証する
    });
}

スペックファイルの実行

後は下記のコマンドで、実行するだけです。

vendor/bin/hhspecify

2015-04-06

Expectationを再設計した話。

PHP Test

expectationを開発していて、ちょっと気に入らない箇所がいくつか出てきたので、再設計してみた。

再設計したので、expectationはもうメンテしておらず、 expectに変わったので、注意してください。また、peridotのプラグインも、peridot-expect-pluginに変わり、再設計した方のものに変わっています。

再設計後のマッチャーAPIは互換性担保しているはず。
設計を見直した点は、下記の通り。

アノテーションを使用するメリットがそんなになかった。

旧ロジックはアノテーションでMatcherのどのメソッドを使用して、評価するかを指定する設計だった。こんな感じで、アノテーションで指定する。
```
 ```php
 /**
  * @Lookup(name="toEqual")
  * @Lookup(name="toBe")
  * @param mixed $actual
  */
 public function match($actual)
 {
     $this->setActualValue($actual);
     return $this->getExpectValue() === $this->getActualValue();
 }

 /**
  * @Lookup(name="toBeTrue")
  */
 public function matchTrue($actual)
 {
     return $this->setExpectValue(true)->match($actual);
 }
 ```
```
アノテーションでエイリアス割り当てられるくらいのメリットぐらいしかなかったので、使わないようにした。
Matcherのソースコードに対する、対応付けがわかりににくい。

Matcherをソースコードと1対1になるようにした。
- 例: toBeTrue -> ToBeTrue.php
- 例: toBeEqual -> ToBeEqual.php
エラーメッセージがわかりにくい。

rspec-expectations、gomegaあたりが、どうしているか参考にした。

Peridotのプラグインを使用していた人へ

移行はそんな難しくなくて、peridot.phpを編集して、ExpectationPluginの部分をExpectPluginにします。基本的にはこれでOKなはず。

use expect\peridot\ExpectPlugin;

return function(EventEmitterInterface $emitter) {
    ExpectPlugin::create()->registerTo($emitter);
};

あとはspec書くだけ。

describe('Example', function() {
    describe('#create', function() {
        it('return new Example instance', function() {
            expect(Example::create())->toBeAnInstanceOf('Example');
        });
    });
});

まとめ

expectationからexpectにパッケージが変わった。
peridot-expect-pluginがexpectを使うようになった。
peridot-expect-pluginは移行が必要。

2015-02-01

いつから俺は、be_truthy/be_falseyの仕様を勘違いしていたのだ

PHP Test

PHPでexpectationライブラリ作っているのですが、思いっきり間違った実装をしていることに、rspecのリファレンスを見ていて、気がつきました。

matcherのtoBeTruthy/toBeFalseyが、rspecのmatcherでは、

be_truthy - nil、若しくはfalseでない
be_falsey - nil、若しくはfalse

なんですね。自分はずっと、be_true / be_falseのエイリアスだと思っていた...。

リファレンスをみるとちゃんと書いてある。

    expect(actual).to be_truthy    # passes if actual is truthy (not nil or false)
    expect(actual).to be_falsey    # passes if actual is falsy (nil or false)

というわけで、バージョン1.4.3で修正しました。
古いバージョンでは、toBeTruthy/toBeFalseyが、toBeTrue/toBeFalseと等価の振る舞いになっています。

2015-01-11

ブログ再開しました。

Blog

昔のブログとかはしばらく、残しておきます。
基本的にすべて封鎖する予定です。

旧ブログ - http://sharedhat.com/
Mootips - http://mootips.org/
プロジェクトサイト - http://sharedlab.net/
ギャラリーテーマ - http://sharedbition.com/

type holyshared = Engineer<mixed>

技術的なことなど色々