Overview
ウェブ開発をしているとどうしても書かざるを得ない仕様書だけど、本当に、本当に面倒臭いよね。
Context/Motivation
- コードと仕様書の2つを同時に更新するなんて無理だよね。
- 絶対ずれるから意味ないよね。
- とはいえ、仕様書って必要になるよね。
- どうにかして一致させられないかな。
というわけで、今回はテストコードからそのまま仕様書を抽出してみました。
仕様書って、一般的にWordpressなどでウェブ制作していてもあまり馴染みがない概念かもしれませんね。
ただ、API開発やウェブ開発では結構使われることが多い印象です。
特に、ユーザーが無数に存在するサービスだと仕様書ってありますよね。
開発と切っても切り離せない仕様書。。。
みなさん頑張って更新されているけども、どうしても手間がかかりますよね。
Get Started!
今回はRailsでテストコードから仕様書を作った場合のアウトプットの紹介です。
一部抜粋して紹介しますね。
Locations
Get /locations
ログインしていない場合
アクセスできる
ロケーションを追加のボタンが出現しない
ログインしている場合
管理者ではない場合
アクセスできる
ロケーションを追加のボタンが出現しない
管理者である場合
アクセスできる
ロケーションを追加のボタンが出現する
こちらは、/locationsというパスでサイトにアクセスした際の挙動(仕様)です。
文字で書いてありますが、自分で書いたわけではなく、テストコードからコマンド1発で出力したものです。
なので、テストコードを書きさえすれば、仕様書を手動で更新する必要はありません。
仕様書としては微妙でしょうか?
それでも、信用できる使用が文章で存在するだけで利用者にとってはありがたいかなって思います。
ちなみに、上記の仕様書ですが、こんな感じのコードから生成されています。
describe "Get /locations" do
context "ログインしていない場合" do
it "アクセスできる" do
visit locations_path
expect(current_path).to eq locations_path
end
it "ロケーションを追加のボタンが出現しない" do
visit locations_path
expect(current_path).to eq locations_path
expect(page).to_not have_content("ロケーションを追加")
end
end
context "ログインしている場合" do
context "管理者ではない場合" do
include_context "login setup"
it "アクセスできる" do
visit locations_path
expect(current_path).to eq locations_path
end
it "ロケーションを追加のボタンが出現しない" do
visit locations_path
expect(current_path).to eq locations_path
expect(page).to_not have_content("ロケーションを追加")
end
end
context "管理者である場合" do
include_context "login setup Admin"
it "アクセスできる" do
visit locations_path
expect(current_path).to eq locations_path
end
it "ロケーションを追加のボタンが出現する" do
visit locations_path
expect(current_path).to eq locations_path
expect(page).to have_content("ロケーションを追加")
end
end
end
いろんな条件やシチュエーションを追加できるので、デグレを防いだりするのに役立ちますね。
何度も同じ画面を確認する必要がなくなります。
Artisanはマンパワーでなりなっているので、効率化や自動化が非常に重要な課題です。
できるだけ省エネで運用していけるように、便利なものはどんどん取り入れていきますよー。
よくあるご質問
Artisanの活動頻度を教えてください
エンジニアなのですが、Artisanに参加できますか?
wordpressのテーマ作れますか?
Artisanってデザイナー?