Hatena::Grouperlang

檜山正幸のErlang未確認情報 RSSフィード

2009-04-02 (木)

ホーア論理とブルートフォース・テスト

| 17:00

ホーア論理に始まりホーア論理に終わる -- 何が? まーともかく、仕様記述つったらホーア論理が基本でしょ。

一方、僕はモンキーテストとかブルートフォース式のテストが好き。理由は、猿とか猿に近い人とかに任せられるから。知的努力をするより、猿に任せた方がバグが出たりする。

受け入れテストをチャンとしている例を知らないのだけど、そもそも「受け入れテストをチャンとする」の意味がわからないし、イメージが湧かない。本来(?)なら、発注側が仕様を決めるから、発注側は仕様に対応するホーア式を持っているべきだろうが、そんな例を知らない。

受け入れテストをもしやるにしても、ブルートフォースになるんじゃなかろうか。実際のところ、リテラルで書かれたエクスペクテーションをイッパイ準備してもらって、はじからチェックするような形だろう。Excelファイルだったりするんだろう。

現実迎合派の僕としては、ブルートフォース・テストで済ませたいし、ブルートフォース or モンキーは絶対にやるべきだとも思っている。また一方、プログラマはホーア式を書くべきだとも思っている。しかし、そのホーア式がブルートフォースと一緒に使えないと意味ない。

つまり、ホーア式による仕様記述、実装プログラムコード、ブルートフォース用のデータ/エクスペクテーションをうまく協調させたい。プログラマがテストを嫌う状況を改善するのはどうも無理な気がするから、せめて「猿にテストさせやすいコードを書く」ように強制したい、圧力をかけたいのだよね。

wbdjkcqcpswbdjkcqcps2013/08/28 02:13vvoskfsmboh, <a href="http://www.teetlxcydi.com/">zeptfodakf</a> , [url=http://www.lfprwfvnog.com/]hrjlynvtod[/url], http://www.gjjqilpgam.com/ zeptfodakf

thxpfkitzuthxpfkitzu2014/03/18 18:03mxfmdfsmboh, <a href="http://www.cgeuxhshnw.com/">jxarsqwhxg</a> , [url=http://www.pfyavtpqjp.com/]pficlukqwf[/url], http://www.alpsvdvtvq.com/ jxarsqwhxg

lelocffzgtlelocffzgt2014/04/12 15:46vsmpafsmboh, <a href="http://www.mvqsrcvjyt.com/">jwqzrmhbxn</a> , [url=http://www.wnopwsfrwr.com/]xmzsismghz[/url], http://www.zpckatvivp.com/ jwqzrmhbxn

2009-04-01 (水)

7つの成分

| 11:03

これだけあれば、アサーションは自由に書けるだろう。

番号 名前 意味 形式
1 LastState 直前の状態 -
2 Fun 呼び出した関数 {Mod, Fun}|no_function
3 Args そのときの引数 [Term]
4 Value 関数の値 {value, Value}|no_value
5 Exception 関数の例外 {Class, Term, Stack}|no_exception
6 State 現在の状態 -
7 Message 関数が出力したメッセージ [Term]

2009-03-31 (火)

コマンドセットの仕様を表すデータ

| 10:34

EUnitもいいんだが、僕のイメージとは違うなー。やっぱ作るしかないのかなー。

  • 事前条件は思い切って捨てよう。
  • 不変条件と事後条件は必ずチェックするようにする。
  • 事後条件をパスすると、付随したアクション(があれば)実行する。

条件=表明の書き方が問題だ。この部分は、EUnitのテスト表現(test representation)が参考になるかも。

コマンド仕様はタプルで記述することにして:

FunSpec = {Mod, FunName, ArgSpec, HelpString?}
Mod = atom()
FunName = atom()
HelpString = string()

ArgSpec = [ (integer() | s | a) ]

CmdSpec = {Cmd, Arity, FunSpec, RplyKind, Assertion?, Action?}
Cmd = atom()
Arity = integer()
RplyKind = v | s | m | vs | vm | sm | vsm 

疑問符は省略可能を表す。AssertionとActionは未定。1文字のアトムの意味は:

  • a 引数全体
  • s 状態
  • v 値
  • m メッセージ

インボーカー(invoker)は、レジスタ(状態)として次を持つ。

  • Value = {value, term()} | no_value
  • State = term()
  • Message = [term()]
  • Exception = {Class::atom(), term()} | no_exception

アサーション関数は、(Value, State, Message, Exception) -> bool() となるだろう。アサーション関数が例外のときは、インボーカーは死ぬ(もう知らん! と)。

[追記]http://d.hatena.ne.jp/m-hiyama-memo/20090331/1238474706 も参照。

事前条件に関しては、関数定義の入り口でassertしてもいいと思う。[/追記]

ValentinaValentina2012/08/24 18:51This piece was cogent, well-witrten, and pithy.

hzkiyhzhzkiyhz2012/08/25 15:48ulmEt6 <a href="http://gcoiyuwzcreu.com/">gcoiyuwzcreu</a>

kpyqduozykpyqduozy2012/08/27 00:13KrkVK3 <a href="http://dmuynnkjqulo.com/">dmuynnkjqulo</a>

dajugzudajugzu2012/08/27 22:29aIT0Zi , [url=http://jjbybzuabnzb.com/]jjbybzuabnzb[/url], [link=http://dffjjwepljnx.com/]dffjjwepljnx[/link], http://nbseayfagmif.com/

2009-03-30 (月)

テキスト型の対話とバッチ処理

| 09:01

to_upper() ->
  Input = io:get_line("to_upper> "),
  if Input =:= eof orelse Input =:= "" orelse Input =:= "\n" ->
      ok;
     true ->
      io:format(string:to_upper(Input)), % 改行はもともと付いている
      to_upper()
  end.

もちろんEシェルで対話できる。

OS> erl -noshell -s foo to_upper -s init stop

としても対話できる。

OS> erl -noshell -s foo to_upper -s init stop <input.txt > output.txt

でもOK。だが、プロンプトがファイルに出てしまう、、、だから isattyが欲しかった。

テストと仕様の融合

| 09:32

EDocとEUnitとナニヤラカニヤラを組み合わせて、最初から「テスト容易=理解容易」なモジュールを書きたいのだが、、、、