【Elixir】ESpec動いた!

漸く動いた(^^)/~

 

使い方をググって見つかったコードはこれ。

GitHub - antonmi/espec: Elixir Behaviour Driven Development

defmodule SyntaxExampleSpec do
  use ESpec
  it do: expect true |> to(be_true())
  it do: expect(1 + 1).to eq(2)
  it do: (1..3) |> should(have 2)
end

 

悩んだところは次の2点。

  1. テスト対象の関数呼び出しってどれ?
  2. テスト対象のモジュールをimport? include? require 等なにかしなくていいの?

mix と ESpec な事例はググっても他に見つからなかった。

 

ので。Spec系の元祖?な RSpec についてググった。

はじめてのRSpec - まずテスト書いてからコード書くシンプルなチュートリアル - Qiita

使えるRSpec入門・その1「RSpecの基本的な構文や便利な機能を理解する」 - Qiita

    it '13歳以上の場合、漢字で答えること' do
      user = User.new(name: 'たろう', age: 13)
      expect(user.greet).to eq '僕はたろうです。'
    end

この記述から、expect(テスト対象関数) .to eq(期待値)という書式であることが分かった。

 

一方、spec/sample01_spec.exs から lib/sample01.ex 内に定義されている Sample01 モジュールを利用するための書式はググってもみつからなかった。

なので、当てずっぽうに import キーワードを使ってみたら当たりだった。

defmodule Sample01Spec do
 use ESpec
 import Sample01

# it do: expect true |> to(be_true())
# it do: expect(1 + 1).to eq(2)
# it do: (1..3) |> should(have 2)

# it do: expect(ret2).to eq(2)

 it do: expect(sumlist([1,2,3])).to eq(6)
 it do: expect(sumlist([2,4,6])).to eq(12)
 it do: expect(sumlist([1,4])).to eq(5)
end

 これで Elixir で BDD できる。

 

次は Scala で BDD だ!( sbt + Spec2 )

【Elixir】BDDな開発環境

Elixirのテスト関連ツールには ESpec と ExUnit があるらしい。

muziyoshiz.hatenablog.com

これらを mix と組み合わせて使う方法を調べる。

Code of Resistance!!: [Elixir]ElixirでもBDDがしたい!!

GitHub - antonmi/espec: Elixir Behaviour Driven Development

Testing with Espec and Elixir – MIKAMAYHEM

【自分メモ】今日の進捗

漸く haskell で stack + hspec を使って BDD な実装・テストをする環境を作れた。

(^^)一番参考になったページ

Behavior-driven development (BDD) in Haskell with Hspec - Tutorials

 

haslkell の開発環境で次にやりたいことは、IntelliJ IDEA Community Edition での開発。インストールはしたものの、stack で作ったプロジェクトのインポートの仕方がよくわからない。また、結構便利そうな機能があるのだが、オペレーションがよくわからない。

 

Elixir の開発環境が Haskell と似ているようなので、次は Elixir で BDD な環境を作ってみよう。

【Vim】小ネタ:短縮入力

HSpec の記述をするとき、shouldbe を毎回入力するのが面倒くさい(^^;

確か、Vim で楽に入力する技があったはず、とググった。

短縮入力 < 入力関連 < 初級編 | viエディタ入門

.vimrc に

ab sb@ `shouldBe`

 と書いておく。で、編集入力中に sb@ と入力した後 spaceキー(又はTabキー)を押すと `shouldBe` に変換される。便利。(^^)

 

当初は sb で登録したのだが、 sb[スペース] とsbの後に半角スペースを入力しようとしたら `shouldBe` に変換された(^^; ので、@を付けた。@sb だと登録できなかったのでsb@ にした。

shouldBe の他にも shouldReturn , shouldThrow があることが分かったので、下記の設定を追加。

ab sr@ `shouldReturn`

ab st@ `shouldThrow`

 -----------

追記。@を付けたのはキーワードそのものを入力したい時のためだったが、キーワード入力後に

ctrl-v を押すと置換されない。

vimの短縮入力(Abbreviations)について -- ぺけみさお

ので、@なしで良さそう。また、文字入力中だけ置換できれば良いので ab ではなく iab のほうがよさげ。

Vimの短縮入力 :ab[breviate] に使える文字・使えない文字 | 牢獄機械文書群

ということで、最終的な ~/.vimrc は

iab sb   `shouldBe`

iab sr    `shouldReturn`

iab st    `shouldThrow`

 

となった。

【ToDo】ミニアプリ

プログラミング言語習得のため、基本文法の演習問題を解いた後どんな練習問題を解けば良いのか考えた。ウェブアプリケーションを作るというのが1つ。しかし、この場合はそれぞれのウェブアプリケーションフレームワークを使うことが前提となる。その前に、フレームワークを使わずに完成させられる小さなアプリケーションを演習問題として作りたい。どうやら、パーサが定番のひとつらしい。いろんな言語の教科書に登場する。

そのあとで、簡単なWebアプリ。こちらはToDoリストとチャットが定番っぽい。

【Haskell】stack と HSpec

stack には HSpec 用のテンプレートがある。

どんなテンプレートがあるかは

stack templates

 で確認できる。自分の環境では

hspec - a testing framework for Haskell inspired by the Ruby library RSpec

 というのが含まれている。これを使ってプロジェクトを作るには

stack new hello hspec

 とすればよい。hello/ というディレクトリが作られている。

hello
├── LICENSE
├── README.md
├── Setup.hs
├── app
│    └── Main.hs
├── hello.cabal
├── src
│    └── Data
│       └── String
│          └── Strip.hs
├── stack.yaml
└── test
   ├── Data
   │     └── String
   │        └── StripSpec.hs
   └── Spec.hs

7 directories, 9 files

【ソフトウェアテスト】xUnit と Spec系の比較

テスティングフレームワークについてググっていたら、どうやら2系統にわかれるっぽい。

xUnit

SUnit(Smalltalk) に始まり、JUnit(Java)、GoogleTest(C++)、HUnit(Haskell), ScalaTest(Scala), ExUnt(Elixir) など。

自分は今までこちらしか使ったことがなかった。

Spec系 

RSpec(Ruby), JGiven(Java), Igloo(C++) , HSpec(Haskell), Spec2(Scala) ,ESpec(Elixir)など。

テストケースの記述にフォーマットが決まっている。given/when/then 

 

どちらを選ぶ?

メジャーな言語は両方の系統を持っていることも多い。Spec系のほうが後から作られただけあって、下記のメリットがありそう。

  1. BDDのツールなので、ユーザ視点で表現する。プログラマ以外の人と仕様をすり合わせしやすい。
  2. 決まり切ったコード(Boilerplate code)を減らせる

とはいえ。システムテスト・受入テストについていえば1のメリットはありそうだが、単体テスト結合テストは開発者が行うテストなので、あまり関係ないかも。

2についていえば、概ね一般論として xUnit より有利、と言えるかもしれないが、実際には各ツールの出来に依存するのではないか?

なので、出来れば両方使ってみて使いやすいほうを使う、というのが正解な気がする。