寝坊したが、すっきりした一日を送れた。

diary

oversleep

午前11時に起床と、だいぶ寝坊をした。

一つはデパスとかゆみ止めで眠気がすごいことになっていたのだろう。

そしてもう一つは、久しぶりに実施した、きつめの筋トレが原因だろう。

health

睡眠と筋トレのおかげか、かなりすっきりした一日を送れた。

ステロイドとかゆみ止めのおかげで手指の荒れがだいぶ落ち着いてきている。が、まだ皮が薄いような気がする。

pray

どうか今日のように実り豊かな一日を送れるように、主よ、どうかお導きください。

弱いところに流れようとする私を支えてください。

喜び、祈り、感謝し、 霊の火を消さず、預言を軽んじず、 全てのものを吟味し良いものを大事にし、 あらゆる悪いものから遠ざかります。

日々の生活をより豊かにするために、どうか、定期的にしっかりと運動させて下さい。

今日の勉強

rust

TRPL pp.228-240

11章のテストの話

テスト関数の本体の典型的な３つの動作

1. 必要なデータや状態をセットアップ
2. テスト対象のコードを走らせる
3. 結果が想定通りであることを断定(アサーション)する

Rustにおけるテスト

• test 属性で注釈された関数
  • 属性とは、Rustコード欠片に関するメタデータのこと
• fnの前に#[test]を付け加えたもの
  • この注釈がテスト関数であることを示
  • テスト実行機はこの関数をテストとして扱うとわかる
• testモジュール内には、
  • テスト関数以外の関数を入れられ、
    • シナリオのセットアップをしたり、共通の処理を行う手助けをしたりもできる。
  • テストだったら#[test]注釈を付けることで、どれがテストする関数かを示す必要がある。
• 各テストは新規スレッドで実行され、テストスレッドが淫だと確認したとき、メインスレッドがテストはFAILEDと印づける
• コンパイラはAPIドキュメントに現れるどんなコード例もコンパイルでき、ドキュメントとコードを同期することができる
• コードに変更を加え、バグを導入したらテスト結果が失敗したら、テストによりバグが補足されたことになる

Compiling
Finished
Running
test tests::(テストする関数の名前) ... (実行結果)
test tests::(テストする関数の名前) ... (実行結果)

(失敗していた場合は、
失敗している各々の関数の失敗理由と
失敗した関数一覧
の2つのフィールドあ出力される)

test result:(総合結果) (成功数、失敗数、無視すると指定したテスト数、ベンチマークテスト用、実行するテストのフィルターがけした数)

(テストが通ったら、ドキュメンテーションテストの結果が出力)

assert!マクロ

• テスト内の何らかの条件がtrueと評価されることを確かめたい時に有用
• 論理値に評価される引数を与える
  • trueなら何もせずにテストは通り
  • falseならpanic!マクロが呼び出されテストは失敗

testモジュールは、

• 通常の公開ルールに従う普通のモジュールであり、
  • 内部モジュールなので、
  • 外部モジュール内のテスト配下にあるコードを、
  • 内部モジュールのスコープに持っていく必要がある

assert_eq!マクロとassert_ne!マクロ

• アサーションが失敗したら、2つの値を出力することもするので、これにより、テストが失敗した原因を確認しやすくなる
  • 失敗したら、2つの引数をleftとrightと表示する
    • Rustでは、expectedとactualのような順序の問題はない
• assert_eq!マクロ
  • テスト下にあるコードの結果をコードが返すと期待される値と比較して、等しいと確かめるために有用
• assert_ne!マクロ
  • 値が何になるであろうか確信が持てないけれども、コードが意図したとおりに動いていれば確実にこの値にはならないとわかっているような場合に有用
• これらのマクロを使うためには、PartialEqトレイトとDebugトレイトを実装していなければならない
  • ==と!=演算子を使用しているからPartialEq
  • デバッグフォーマットを使用してプリントしているのでDebug
  • これらを実装するには、単純に構造体やenum定義に#[derive(PartialEq,Debug)]と注釈を追加すればよい。

1on1

『ヤフーの1on1』は結構面白い本であると感じた。

現在5分の3ほど読んだ。読み終えたら、再度読んで、メモを作ろうと思う。

isabelle

Concrete Semantics pp. 172-174

Knaster-Tarski fixpoint theoremを読む。 単調性だけえ、最小のpre-fixointを導きだせるので、すごい性質だと思う。 これで、変数のLiveをちゃんと記述できることの確証に繋がる。

証明や定義を読んでいて、思ったが、圧倒的に証明力が落ちていると感じた。