読者です 読者をやめる 読者になる 読者になる

酔いどれエンジニアのブログ

有限会社wisdomのスタッフブログです。主にプログラミングやアプリケーション開発の話題を書いていきます。

受講生はどういう教育過程を経ているか | 教育のことで頭が混乱したので、頭の中をスクラップ&ビルドする 2

新人教育について色々考えていて、頭が混乱してきたので、整理するためのシリーズです。 前回の「名称の意味を確認する | 教育のことで頭が混乱したので、頭の中をスクラップ&ビルドする 1 」では名称だけ確認しました。 今回は受講生について考察をしたいと思います。
 

私が携わっている研修では最終学歴が大学卒業である人が多いです。 最終学歴が高専卒業生や専門学校卒業生はごく少数で、高校卒業生に至っては受け持ったことがありません。

最終学歴が高専卒業生や専門学校卒業生が少ないのは、高専卒業生や専門学校卒業生をほぼ即戦力として採用しているからでしょう。 (この辺りの裏付けを取る資料を探してみましたが、求めるものが細かすぎて当てはまるものが見当たりません。各学校の就職先を調べ、その企業の募集要項などから新人教育に関する記述を調べれば分かると思いますが、さすがに時間が取れないので、ここは私の憶測を元に進めて行きたいと思います。)

 

高校とは

他の学校を調べてみる前に、比較基準として高校を調べてみます。

第五十条 高等学校は、中学校における教育の基礎の上に、心身の発達及び進路に応じて、高度な普通教育及び専門教育を施すことを目的とする。

第五十一条 高等学校における教育は、前条に規定する目的を実現するため、次に掲げる目標を達成するよう行われるものとする。 一 義務教育として行われる普通教育の成果を更に発展拡充させて、豊かな人間性、創造性及び健やかな身体を養い、国家及び社会の形成者として必要な資質を養うこと。 二 社会において果たさなければならない使命の自覚に基づき、個性に応じて将来の進路を決定させ、一般的な教養を高め、専門的な知識、技術及び技能を習得させること。 三 個性の確立に努めるとともに、社会について、広く深い理解と健全な批判力を養い、社会の発展に寄与する態度を養うこと。

引用元:学校教育法  第六章 高等学校

社会に役立つ知識、技術を習得させる<教育>を行う場が高校であるようです。

 

大学とは

それでは一番対象者の多い大学とは本来どういうところなのかを確認します。

第八十三条 大学は、学術の中心として、広く知識を授けるとともに、深く専門の学芸を教授研究し、知的、道徳的及び応用的能力を展開させることを目的とする。 ○2 大学は、その目的を実現するための教育研究を行い、その成果を広く社会に提供することにより、社会の発展に寄与するものとする。

引用元:学校教育法  第九章 大学

高校とはだいぶ趣きが違いますね。 専門の学芸に関する知識を教授されたり研究を行うことで、 自分で考える力を手に入れるための学校と言えそうです。

第七条 大学は、学術の中心として、高い教養と専門的能力を培うとともに、深く真理を探究して新たな知見を創造し、これらの成果を広く社会に提供することにより、社会の発展に寄与するものとする。 2 大学については、自主性、自律性その他の大学における教育及び研究の特性が尊重されなければならない。

引用元:教育基本法 第七条

「深く真理を探求して新たな知見を創造し」と書かれています。 受動的だった高校までとは大きく違うところですね。

つまり大学卒業者は、その專攻や学校に関係なく、自らの力で物事を考え抜く能力を持っていると言えるでしょう。

 

大学全入時代

しかし、大学全入時代と言われる昨今では、実体が変わってきているようです。 大学全入時代とは、入学定員の総数が受験者数よりも多いので、学校・学部にこだわらなければ全員が大学に入ることが出来るということを意味しています。 このような状態ですから、大学側も学生に選んで貰うために変わってきたようです。 その結果でしょうか、<自らの力で物事を考えぬく能力>を持たぬまま卒業してしまう人も増えてきたように思います。

ただ、ほとんどの大学卒業者は<自らの力で物事を考えぬく能力>を変わらず持っていますから、受講生の中には<自らの力で物事を考えぬく能力>を持ってない人がいる可能性があるという認識を持っておいた方が良いようです。

名称の意味を確認する | 教育のことで頭が混乱したので、頭の中をスクラップ&ビルドする 1

社員教育のことを色々と考えていると、頭が混乱して来ました。
こういう時は一度頭の中をまっさらにして、再構成するのが一番だと思うので、そうして見たいと思います。

というわけで、今回は用語の確認から。

教育と学習

とりあえずとっかりとして、タイトルに出ている<教育>。
そしてセットで使われることの多い<学習>について確認したいと思います。

教育

「教育」は辞書には以下のように記されています。

他人に対して、意図的な働きかけを行うことによって、その人間を望ましい方向へ変化させること。広義には、人間形成に作用するすべての精神的影響をいう。その活動が行われる場により、家庭教育・学校教育・社会教育に大別される。
「子供を―する」「義務―」「―のある人」

引用元:Weblio辞書

<教育>は他者に対する働き掛けですね。

学習

それでは「学習」はどうでしょうか。

(1)まなびおさめること。勉強すること。
「新しい教科を―する」
(2)〔生〕 生後の反復した経験によって、個々の個体の行動に環境に対して適応した変化が現れる過程。ヒトでは社会的生活に関与するほとんどすべての行動がこれによって習得される。
(3)〔心〕 過去の経験によって行動の仕方がある程度永続的に変容すること。新しい習慣が形成されること。
(4)〔教〕 新しい知識の獲得、感情の深化、よき習慣の形成などの目標に向かって努力を伴って展開される意識的行動。

引用元:Weblio辞書

<学習>は自分が対象です。

つまり対象者に<学習>させる、<学習>に向かわせるように働きかけることが<教育>と言えそうです。

文部科学省が告示する教育課程の基準を<学習指導要領>と言うことから、この認識で間違い無いでしょう。

授業と講義

それでは教育の手段である<授業>と<講義>とは何かを確認してみてみたいと思います。

授業

学校などで、学問などを教えること。 「―を受ける」「講師として―する」

引用元:Weblio辞書

講義

(1)人々に学説や書物あるいは物事の意味や内容を口頭で説明すること。学問的な話をすること。また、その話。
「社会情勢について―する」
(2)大学における授業。

引用元:Weblio辞書

なんか講義の意味に授業とか書いてあるし、ややこしいですね。
「大学における授業」と書かれているので、大学に関する資料を調べたところ大学設置基準を見てみたところ、第二十五条に以下のような記述がありました。

授業は、講義、演習、実験、実習若しくは実技のいずれかにより又はこれらの併用により行うものとする。

引用元:大学設置基準

<講義>は<授業>の形態の一つのようです。

教師と講師

次に教育を行う側の呼び方である<教師>と<講師>を確認してみます。

教師

(1)学校などで、学問・技能・技術などを教える人。先生。教員。

(2)宗教上の指導をする人。

引用元:Weblio辞書

講師

(1)講演会や講習会で講演・講義をする人。

(2)大学などで、教授・助教授に準ずる職務にあたる教員の職名。
→こうじ(講師)

引用元:Weblio辞書

これだと全く違いが分かりませんね。違いはないんでしょうか。
学校教育法を見てみると、<教師>という言葉は使われておらず、<教諭>あるいは<講師>という言葉が使われています。

教諭

1)おしえさとすこと。
「正道を説き人に―す/花柳春話(純一郎)」

(2)教育職員免許法に基づく普通免許をもち、学校教育に従事する者。小・中・高の学校、盲学校、聾学校、養護学校および幼稚園の正教員。旧制では、中等学校の正教員。

引用元:Weblio辞書

つまり、<教師>の中で、教員免許を持ち学校で働いている人が<教諭>。
それ以外は<講師>と呼べるという事のようです。

新人教育として関係ありそうな名称と似た名称についての線引きはひとまず出来たと思うので、次回は研修の対象者について考察してみたいと思います。

XCodeのBDDツールであるKiwiのGetting Started with Kiwi 2.0を和訳してみた。その2

前回に引き続きGetting Startedを和訳するの続きです。

間違っているところがあれば、ご指摘頂けると幸いです。

Step 3: Schemes

またトリッキー。 注力する全体の方向性を再検討しましょう。 我々は可能な限り少ない手間でアプリケーションのコードをテストすることができるようにワークスペースを設定したいです。 正しく前の手順を行ったなら、テストとして実行される一連のテストに構築中のユニットテスト・ターゲットを持っているはずです。 しかし、我々はこのテスト・フェーズでどうやって正確に手に入れられるでしょうか。

Xcodeはプロダクトを構築し実行する時に、どの構築するための目標と設定を使用するかを把握するために、"Scheme"と呼ばれるものを使用しています。 スキームを加え、数多く構成することができますので、ほとんどの環境に適合させることができる最も簡単なケースに焦点を当てます。

1.Scheme管理ウィンドウを開きます:

 Product -> Scheme -> Manage Schemes…

率直に言います。 私はあなたがここで何を見るつもりなのか見当が付かない。 ここに記載されている一つまたはいくつかのSchemeを、独自に作成していった手順によって、ここにたどり着くまでに、既に持っているかもしれません。

幸いにも、我々は明確な目標を持っています。 私たちは、ユニットテスト・ターゲットを使用して"Test"アクションを持っている我々のアプリケーションを実行する時に使用されるSchemeを変更したい。

2.アプリケーションを実行する時に使用するSchemeを選びます。 この意味が理解できない場合は、プロジェクトと同じ名前が付けられたSchemeを選択して下さい。そのようなスキームが無い場合は...思うに。本当ですか。そしたら私にメールをして下さい。

3.Schemeを編集します:

Edit …

4.左側ペインの "テスト"アクションを選択します。 5.ユニットテスト・ターゲットが"Test"のリストに表示され、チェックされていることを確認して下さい。 表示されていない場合は、[+]ボタンを押してそれを追加します。

できた、できた!

Step 4: Write a Test

最後の仕事である実際のテストを書く作業に取り掛かることができます。 これは、アプリケーションのさまざまな部分のテストを書くときに繰り返されるステップです。 すべてが正しく設定されていることを確認するためのごく簡単なテストケースを作成します。

1.プロジェクトを右クリックして、テストケースをプロジェクトに追加します。

# iOS
New File... -> Cocoa Touch -> Objective-C test case class
# OSX
New File... -> Cocoa -> Objective-C test case class

2.クラス名を SampleSpec にして"Next"を選択します。

3.ユニットテスト・ターゲットだけがチェックされている事を確認したら、"Create"を選択します。これでテストのコードはユニットテスト・ターゲットの中にだけ存在し、アプリケーションの中には存在しない状態になります。

4.XCodeに自動生成された.hファイルを削除します。 また、あなたの好みに応じて.mファイルをどこかに移動しても大丈夫です。

5..mファイルを開き、以下の内容に書き換えます。

 #import "Kiwi.h"

SPEC_BEGIN(MathSpec)

describe(@"Math", ^{
     it(@"is pretty cool", ^{
         NSUInteger a = 16;
         NSUInteger b = 26;
         [[theValue(a + b) should] equal:theValue(43)];
     });
});

SPEC_END

6.上記のStep 3で設定したSchemeが実行バーで選択されていることを確認します。選択されている場合は、さしあたりのシミュレータを選ぶことをお勧めします。テストを実行する時はCmd-U (デフォルトのホットキー)を押すか、または:

Product -> Test

7.Xcodeには、その策略を通過し、いくつかのポイントであなたのテストを実行する必要があるでしょう。(訳注:ちょっとここ意味が分かりません) 少しした後、Xcodeがエラーを報告するはずです。成功しました!XcodeはIssue Navigator(左側のペインにある4番目のタブ)を役立つようにポップアップすることでしょう。

8.失敗箇所の一つをクリックすると、問題がおきた正確な場所が開きます。 9.エラーを修正します。- あなたが方法を尋ねる必要があるならば... 10.もう一度テストを実行します (step 6)。 11.テストを実行したら、エラーは報告されないはずです。成功!

あなたは、アプリケーションのテストを実行するための環境を上手く設定できました。いい感じにしたいアプリケーションの、あらゆる面に対するテストを加えるには、このステップを繰り返してください。

Step 5: Next Steps

それで、あなたはテストを書きたい?

うまく行けば、今あなたはプロジェクトにKiwiのテストをセットアップする方法を十分に知っています。 次の骨の折れる部分は、あなたの時間を無駄にせずに、なにをどうやってテストをするか考え出すことです。

Kiwiのwikiは追加ガイドなどによって、これからも拡張されて行きます。(お気軽に寄稿して下さい!) それまで適切なテストについて学ぶのには Daniel SteinbergよるKiwi Bookが非常に参考になるでしょう。 セットアップ手順については少し古いですが、内容はしっかりしています。

Feedback

フィードバックはこちらのemailに。allen@lentor.io ガイドを作るのは大変な作業ですが、 以下の人々のフォローに助けられました。

  • chrishulbert
  • dimsumthinking
  • frosty
  • jeffremer
  • jonah-carbonfive
  • MaxGabriel
  • mneorr
  • shepting
  • sojinkim

ブログシステムを作りながらRailsを学ぶ(9) ユースケースシナリオに対するテストのfeature(Turnip)を作成する

前回、「記事を閲覧する」のユースケースシナリオを記述しました。 そして第6回にはTurnipというテストツールをインストールを入れました。 今回はユースケースシナリオを元にTurnipで動くテストを記述していきます。

まずはユースケースシナリオを見返してみます。

ユースケースシナリオを見返す

■ 基本フロー
1. ユーザーはブログシステムにアクセスする。
2. システムはブログの記事一覧を表示する。(ex-1
3. ユーザーは見たい記事の「もっと見る」リンクを押下する。
4. システムは選択された記事の詳細を表示する。(ex-2

■ 代替フロー
ex-1) 記事が1件もなかった場合
1. システムは登録されている記事がない旨を表示する。
2. このユースケースを終了する。

ex-2) 選択された記事が削除されていた場合
1. システムは選択した記事は削除された可能性がある旨を表示する。
2. このユースケースを終了する。

■付帯事項
・一覧は登録日時順が新しいものから順に表示する。
・一覧に一度に表示する記事の数は20件。
・一覧に表示している記事より古い記事が存在する場合「古い記事」リンクが表示される。
 「古い記事」を押すと表示している記事より古い20件までの記事が表示される。
・一覧に表示している記事より新しい記事が存在する場合「新しい記事」リンクが表示される。
 「新しい記事」を押すと表示している記事より新しい20件までの記事が表示される。

大きく見て基本フロー1つと、代替フロー2つの、3つのパターンがあることがわかります。
また、付帯情報から、20件が境界値となり、テストパターンが作られることが分かると思います。
ただし、これらを確認するテストケースを今から作るケースに全て入れてしまうと、テストケースが膨れ上がってしまうため、別のテストフェーズで行うべきかもしれません。
これらのことを加味してテストを作って行きます。

テストに関係するフォルダとファイルを作成する

hoge-blog配下に以下の様にファイルとフォルダを作成します。

hoge-blog
  - spec
    - features
      - articles_index.feature
    - steps
      - articles_index_steps.rb
    - spec_helper.rb
spec
rspecコマンド実行時にデフォルトでテストを検索しにいくフォルダ
features
featureファイルを格納するフォルダ。
featureファイルにはその機能が実装できたと言う基準となるシナリオを記述します。
steps
stepsファイルを格納するフォルダ。 stepsファイルにはfeatureに記述するステップの実態を記述します。
spec_helper.rb
テストに対する共通の設定などを記述します。

featureファイルにフローに対応するシナリオを記述する

基本フローと代替フローをに対応するシナリオを記述すると以下のようになる。

# encoding: utf-8
# language: ja

機能: 記事を閲覧する 
シナリオ: 記事を正常に閲覧する
  前提 テストデータは20件データを使用する

  もし ブログシステムにアクセスする
  ならば 記事が20件表示されている

  かつ 18件目の記事の「もっと見る」リンクを押下する
  ならば 18件目の記事の内容が表示される

シナリオ: 記事が1件もなかった
  前提 テストデータは0件データを使用する

  もし ブログシステムにアクセスする
  ならば 「まだ記事は書かれていません」と表示される

シナリオ: 選択された記事が削除されていた
  前提 テストデータは20件データを使用する

  もし ブログシステムにアクセスする
  ならば 記事が20件表示されている

  かつ 18件目の記事をデータベースから削除する
  かつ 18件目の記事の「もっと見る」リンクを押下する
  ならば 「この記事は削除された可能性があります。」と表示される

それでは実行してみましょう

$ rspec

#.rspecファイルを作ってない場合
$ rspec -r turnip/rspec  

#specフォルダ配下に作ってないか、任意のものだけ実行したい場合
$ rspec  spec/features/articles_index.feature 

#フル指定。
$ rspec  -r turnip/rspec spec/features/articles_index.feature 

実行結果が以下のようになったと思います。 コメントを見るとわかるようにアクションや判定にあたる箇所に対応するStepが見つからなかったため、Pendingされてしまいますが、今はこれでOKです。

***

Pending:
  記事を閲覧する 記事を正常に閲覧する テストデータは20件データを使用する -> ブログシステムにアクセスする -> 記事が20件表示されている -> 18件目の記事の「もっと見る」リンクを押下する -> 18件目の記事の内容が表示される
    # No such step: 'テストデータは20件データを使用する'
    # ./spec/features/articles_index.feature:68
  記事を閲覧する 記事が1件もなかった テストデータは0件データを使用する -> ブログシステムにアクセスする -> 「まだ記事は書かれていません」と表示される
    # No such step: 'テストデータは0件データを使用する'
    # ./spec/features/articles_index.feature:68
  記事を閲覧する 選択された記事が削除されていた テストデータは20件データを使用する -> ブログシステムにアクセスする -> 記事が20件表示されている -> 18件目の記事をデータベースから削除する -> 18件目の記事の「もっと見る」リンクを押下する -> 「この記事は削除された可能性があります。」と表示される
    # No such step: 'テストデータは20件データを使用する'
    # ./spec/features/articles_index.feature:68

Finished in 0.0016 seconds
3 examples, 0 failures, 3 pending

付帯事項を加味したシナリオを付け加える

それでは更に付帯事項をテストケースにつけてもう少し複雑にしてみます。 加える点は以下の通りです。

  • 表示順が新しいものからになっているか
  • 一度に表示さている記事の数は20件か
  • 古い記事が存在する場合「古い記事」リンクが表示されるか
  • 「古い記事」を押すと古い記事が表示されるか
  • 新しい記事が存在する場合「新しい記事」リンクが表示されるか
  • 「新しい記事」を押すと新しい記事が表示されるか
# encoding: utf-8
# language: ja

機能: 記事を閲覧する 
シナリオ: 記事を正常に閲覧する
  前提 テストデータは20件データを使用する

  もし ブログシステムにアクセスする
  ならば 20件目から1件目までの記事が順番に表示されている
  かつ「古い記事」リンクが表示されていない
  かつ「新しい記事」リンクが表示されていない


  かつ 18件目の記事の「もっと見る」リンクを押下する
  ならば 18件目の記事の内容が表示される

シナリオ: 記事を迷いながらも正常に閲覧する
  前提 テストデータは50件データを使用する

  もし ブログシステムにアクセスする
  ならば 50件目から31件目までの記事が順番に表示されている
  かつ「古い記事」リンクが表示されている
  かつ「新しい記事」リンクが表示されていない

  かつ 「古い記事」リンクを押下する
  ならば 30件目から11件目までの記事が順番に表示されている
  かつ「古い記事」リンクが表示されている
  かつ「新しい記事」リンクが表示されている

  かつ 「古い記事」リンクを押下する
  ならば 10件目から1件目までの記事が順番に表示されている
  かつ「古い記事」リンクが表示されていない
  かつ「新しい記事」リンクが表示されている

  かつ 「新しい記事」リンクを押下する
  ならば 30件目から11件目までの記事が順番に表示されている
  かつ「古い記事」リンクが表示されている
  かつ「新しい記事」リンクが表示されている

  かつ 18件目の記事の「もっと見る」リンクを押下する
  ならば 18件目の記事の内容が表示される


シナリオ: 記事が1件もなかった
  前提 テストデータは0件データを使用する

  もし ブログシステムにアクセスする
  ならば 「まだ記事は書かれていません」と表示される

シナリオ: 選択された記事が削除されていた
  前提 テストデータは20件データを使用する

  もし ブログシステムにアクセスする
  ならば 20件目から1件目までの記事が順番に表示されている

  かつ 18件目の記事をデータベースから削除する
  かつ 18件目の記事の「もっと見る」リンクを押下する
  ならば 「この記事は削除された可能性があります。」と表示される

付け加えたら実行して記述ミスがないことを確認します。

$ rspec

リモートリポジトリに送信する

ここまでで今回は終了ですので、変更をリモートリポジトリに送っておきましょう。

$ git add .
$ git commit -am "ユースケースシナリオに対するテストのfeatureを作成する"
$ git push origin edit_articles_index

XCodeのBDDツールであるKiwiのGetting Started with Kiwi 2.0を和訳してみた。その1

前回はReadmeを訳しましたが今回はGetting Startedを和訳して見たいと思います。

今回も前回同様、意訳している箇所があります。 間違っているところがあれば、ご指摘頂けると幸いです。

途中でいやになってきたので、2回に分けたいと思います。

Getting Started with Kiwi 2.0

このガイドは、iOSOS XプロジェクトにKiwiを使用する方法を学ぶための出発点です。

このガイド(またKiwi)のゴールはアプリケーションのコードを実行したり、プロファイリングしたりするのと同じぐらい簡単に、テストを行うことが出来るワークスペースを設定することです。

必要条件:

Xcode iOS OS X
4.5+ 5.0+ 10.7+

Step -1: CocoaPods

すでにCocoaPodsをインストールしている場合は、この手順を省略します。 現代のiOSOS Xの開発では、必然的にプロジェクトでオープンソースのライブラリ(例えばAFNetworking)を使用することになります。 その結果、ライブラリ管理をさらに複雑にします。 CocoaPodsはこの苦痛を少なくしてくれる、私達が好むライブラリ管理ツールです。

1.CocoaPodsのインストール

$ [sudo] gem install cocoapods
$ pod setup

2.最後に、Xcodeツールがコマンドラインから使用可能であることを確認する必要があります。 Xcodeを開き、Command Line Toolsがインストールされているか確認して下さい。インストールされてなければ、インストールして下さい。

Preferences -> Downloads -> Components -> Command Line Tools -> Install

(訳注:私の環境ではコンポーネント一覧にある「Command Line Tools」をダブルクリックするとダウンロードが始まりました。)

Step 0: Setting Up a Unit Test Target

既にプロジェクトにUnit Test Targetを設定している場合は、このステップを飛ばして下さい。 プロジェクトにKiwiを加えるには、テスト時にXcodeから実行されるユニットテスト・ターゲットが必要です。 プロジェクト作成時にプロジェクト・ウィザードで「Add Unit Tests」にチェックを入れて作成したか、作成後にユニットテストターゲットをプロジェクトに追加してあれば、準備は完了しています。

Project Navigatorでプロジェクトを選択し、プロジェクトのTargetsを確認して下さい。ユニットテストのターゲットが既に存在する場合は、この手順を省きます。ユニットテストのターゲットがなければ、次の手順を実行し追加して下さい。

ユニットテスト・ターゲットは既にあるかもしれません 無ければユニットテスト・ターゲットを追加して下さい
設定済 未設定

1.Project Navigatorでプロジェクトを選択します。 2.プロジェクトに"Cocoa Touch Unit Testing Bundle"を追加して下さい。:

File -> New -> Target... -> Other -> Cocoa Touch Unit Testing Bundle

3.ユニットテスト・ターゲットに適切な名前(例えば、 "AmazingAppTests")を設定します。 テストをしたいプロジェクトが "Project" に反映されていることを確認したら "Finish"をクリックして下さい。

ユニットテスト・ターゲットは、プロジェクトに設定されたことでしょう。 先に進む前に、ユニットテスト・ターゲットの名前(上記の"AmazingAppTests")をしっかりと覚えておいて下さい。

Step 1: Installing Pods

次のステップでは、プロジェクトのPodfileを作成、または更新します。 CocoaPodsでライブラリ管理を行うと、どのようになるかを説明します。 Kiwiをインストールするために、ファイルにKiwiのエントリーを加えましょう。

1.後ほど再度開くことがありますが、まずXcodeを閉じます。 2..xcodeprojファイルがあるディレクトリにPodfileという名前の新しいファイルを作成します。すでにPodfileが存在する場合は、それを編集します。 下記のようにPodfileを変更して下さい。前のステップで指定したターゲット名を使用して下さい。

 # Podfile

# 下記の適切なプラットフォームを選択
# Kiwiでサポートされている最小限なiOSのバージョン(またはそれ以降)を指定
platform :ios, '5.0'
# platform :osx

#
# 他にいくつかのエントリーが、既にファイルに存在するかもしれません。
# ...
#

# AmazingAppTestsターゲットの排他的な依存関係としてKiwiを追加
target :AmazingAppTests, :exclusive => true do
   pod 'Kiwi'
end

#Xcode 5で作った新しいプロジェクト
#(OCUnitベースの代わりにXCTestベース)では、こちらを使用します:
target :AmazingAppTests, :exclusive => true do
   pod 'Kiwi/XCTest'
end

3.プロジェクトのpodsをインストールします。 CocoaPodsはプロジェクトに必要なライブラリをダウンロードして設定します。

$ pod install

4.CocoaPodsがアドバイスを示しますので、それに従って下さい。今後、プロジェクトへの作業は .xcworkspace ファイルを開いて作業して下さい。

$ open myproject.xcworkspace

Step 2: Unit Test Target Configuration

この部分はトリッキーです。よく読んでください。 このステップの目的は以下を確実にこなすことです。 1. ユニットテストのターゲットが正しく構築すること 2. 構築したユニットテスト・ターゲットがロードされ、テストを実行するときに、アプリケーションの実行可能ファイルに正しく注入されること

次に移る前に少しだけユニットテスト・ターゲットについてお話しします。 Kiwiを動かすにはアプリケーションのコードをテストするための、テスト(スペックとも呼ばれる)を書かなければなりません。 アプリケーションのコード(例えば.mファイルなど)はアプリケーション・ターゲットに構築するだろうし、テストはユニットテスト・ターゲットに構築するべきです。 ですので、作成するすべてのテストファイルがユニットテスト・ターゲットに追加されていることを確認してください。

以下のすべての手順は、"Debug"と"Release"の該当する箇所が対象となります。

  1. .xcworkspaceをまだ開いてなければ、開いて下さい。 プロジェクト内に"Pods-.xcconfig"というファイルがあることを確認して下さい。このファイルは、CocoaPodsによって生成されたもので、ユニットテスト・ターゲットのビルド時に使用される特別な設定を含んでいます。

  2. Project Navigatorでプロジェクトを選択し、 "Info"ペインでプロジェクト(ユニットテスト・ターゲットではない方)を選択します。 (訳注:XCode5では、Project Navigatorでプロジェクトを選択し、Project(Targetではなく)の中のプロジェクトを選択、"Info"を選択)

  3. Pods-.xcconfigはConfigurations内の全てのユニットテスト・ターゲットに設定されていることを確認します。 これが設定されているとユニットテスト・ターゲットはxcconfigファイルから構成されている設定を取得することができます。

  4. ユニットテスト・ターゲットを選択し、さらに"Build Settings"ペインを選択します。

  5. "Other Linker Flags"に -ObjC -framework SenTestingKit が設定されていることを確認します。 (訳注: 'Kiwi/XCTest'をインストールした場合は、-ObjC -framework XCTest) これは、(i) SenTestingKitに対してバイナリをリンクすると、(ⅱ )ビルドした時にその他のコードから使用されていないと、リンカーが判断しても、バイナリーから、Kiwiのシンボルが削除されないことを保証します。

  6. このステップでは、アプリケーションの実行可能ファイルが、テストを実行した時にロードされるように設定します。(static libraryが対象の場合は、この手順は必要ありません。このフィールドを空白のままにしておけます。) 以下の"MyProject"をアプリケーションのプロジェクト名に、"ApplicationTargetName"をターゲット名に替えて下さい。その際には大文字と小文字を区別して下さい。(デフォルトではプロジェクト名とターゲット名は同じです。)
    iOSが対象の場合は、"Bundle Loader" を以下のように設定します。 $(BUILT_PRODUCTS_DIR)/MyProject.app/ApplicationTargetName.
    OS Xが対象の場合は、"Bundle Loader" を以下のように設定します。 $(BUILT_PRODUCTS_DIR)/MyProject.app/Contents/MacOS/ApplicationTargetName.

(訳注:XCode5の場合、"Bundle Loader"はProject Navigator→対象プロジェクト→Build Settings→All→Linking の中にあります)

  1. "Test Host"に$(BUNDLE_LOADER)が設定されていることを確認します。 これは、ユニットテストに注入される実行可能ファイルを指定することになります。 $(BUNDLE_LOADER)の値は"Bundle Loader"に設定した値と一致します。 (static libraryが対象の場合は、この手順は必要ありません。このフィールドを空白のままにしておけます。) (訳注:XCode5の場合、"Test Host"はProject Navigator→対象プロジェクト→Build Settings→All→Unit Testingの中にあります)

XCodeのBDDツールであるKiwi のReadmeを訳してみた。

以前にOSXアプリで使えるBDDがないとか書いてたんですが、Getting-Startedを読んでみたらOSXアプリでも使えるっぽいので、理解を深める意味でReadmeとGetting-Startedを訳してみたいと思います。

今回はReadmeが対象です。

意訳している箇所もありますが、お役に立てれば幸いです。 また間違っているところがあれば、ご指摘頂けると幸いです。

Simple BDD for iOS

KiwiはiOSアプリ開発のための振る舞い駆動型開発(BDD)用ライブラリです。 簡単に設定できて使えるBDDライブラリを提供することを目指しています。

Why?

Kiwiの着想の背景は、テストをバンドルされているテストフレームワークよりも読み易くすることです。

テスト(というか仕様)はObjecttve-Cで書くことができ、またXcode上でテストやエラー報告を出しゃばらずシームレスに実行できる快適なテスト環境を提供します。

仕様は次のようになります。

describe(@"チーム", ^{
    context(@"新しく作成された時", ^{
        it(@"名前が必要", ^{
            id team = [Team team];
            [[team.name should] equal:@"Black Hawks"];
        });

        it(@"11人の選手が必要", ^{
            id team = [Team team];
            [[[team should] have:11] players];
        });
    });
});

Documentation

Kiwi Wiki は公式ドキュメントソースです。

Getting it

Kiwiは CocoaPodsを使用して取得されることをお勧め致します。 インストールの詳細やその他の事に関しては、Wikiをご覧ください。


以上となりますが、同じように書いた記事「CocoaPodsとは何か知るために訳してみた」がありますので、合わせて御覧ください。

Rubyで作ったスクリプトをgem化して、一人でひっそりと使う方法

Rubyでスクリプトを書いていたんですが、色々なプロジェクトで使うので、非公開でgem化できないかと調べていました。

結果としては、ソースはprivate repositoryで管理して、gemはそのソースを元に作成することにしました。

以下はその手順です。

前提

既にスクリプトはRubyで作ってあるものとします。 便宜上、gem_testという名前のgemを作成することにします。 なお、名前に-(ハイフン)を入れると、そこで切られてしまいModule名やフォルダが分けられてしまいますので、お気をつけ下さい。

手順

gemプロジェクトのテンプレート作成

$ bundle gem gem_test

これによりgem_testフォルダ配下にファイルが作成されます。 これからの作業は全てgem_test配下で行います。

起動ファイルを配置

binフォルダを作りコマンドと同じ名前でrubyのスクリプトファイルを配置します。 たとえば、gem_test_startというコマンドで実行したい場合は、以下のようになります。

gem_test/bin/gem_test_start
gem_test/lib/gem_test.rb
gem_test/lib/gem_test/version.rb
gem_test/Gemfile
gem_test/LICENSE.txt
gem_test/gem_test.gemspec
gem_test/Rakefile
gem_test/README.md

Gemspecファイルを修正

gem_test/gem_test.gemspecを編集します。 最低限、下記の項目を書き換えておきましょう。 書き換えて置かないとgemファイル作成時にこけたり、警告されたりします。

  spec.description   = %q{<<適切な説明>>}
  spec.summary       = %q{<<適切な概要>>}
  spec.homepage      = "https://適切なURL"

次にコマンド名をexecutablesに設定します。 たとえば、、gem_test_startというコマンドで実行したい場合は、以下のように設定します。

spec.executables   = ['gem_test_start']

複数設定したい場合はカンマで区切ります。

spec.executables   = ['gem_test_start', 'gem_test_end']

起動ファイル以外のファイルを配置

起動ファイル以外のファイルはlib配下に配置します。 例えばinstall.rbstart.rbgem_test_startでrequireする場合は以下のようになります。

gem_test/bin/gem_test_start
gem_test/lib/gem_test.rb
gem_test/lib/gem_test/version.rb
gem_test/lib/gem_test/install.rb
gem_test/lib/gem_test/start.rb
gem_test/Gemfile
gem_test/LICENSE.txt
gem_test/gem_test.gemspec
gem_test/Rakefile
gem_test/README.md

requireのパスを変更

libがrequireの開始位置となりますので、それ以下のパスを指定します。 具体的には以下のように指定します。

require "gem_test/install"
require "gem_test/start"

新しく追加したファイルをgitに追加する

bundle gemした時点でgitのローカルリポジトリが作成され、初期ファイルは追加された状態になっています。 また、gemファイルを作る際にはgitに追加されいるファイルを、gemファイル内に含めるようになっています。

git add .

gemファイルを作成する

gem build gem_test.gemspec

gemファイルをインストールする

rake install

実行する

gem_test

最後に

以上で終了です。 gemに含めるファイルをgitに追加しましたが、gemspecファイルを書き換えることでgit以外にも対応可能です。 書き換え対象は以下の場所です。

  spec.files         = `git ls-files`.split($/)

またrequireの開始位置も以下の場所を変えることによって、変更可能です。

  spec.require_paths = ["lib"]

ブログシステムを作りながらRailsを学ぶ(8) ユースケースシナリオを記述する

前回の記事でユースケースを記述しましたが、「コメントをする」というユースケースを忘れておりました。これがないとブログを題材に選んだ意味がないので、ユースケースを修正しました。

ユースケース図

前回作ったユースケース図はテストを作成したいがために作成したのですが、なぜコーディングより先にテストを作成したいかと言うと、先にテストを作成するということは、その機能の仕様を決めるということになるからです。

そして仕様を決めるということは、ゴールを決めるということになります。 ゴールが決まらないと、進む方向が分かりませんし、いつまで経っても完了(到達)しません。

テストを最初に作ると作るものがハッキリしますし、何より出来たという実感が湧くので精神的にとても良いです。

ユースケースからシナリオを作成する

さて、今回はユースケース図を元にユースケースシナリオを作成したいと思います。 ユースケースシナリオを作成することで、テストケースのパターンが明らかになります。 今回は「記事を閲覧する」ユースケースを対象に作成します。

ユースケースシナリオでは、対象となるユースケースを達成するために、ユーザーやシステム等がどういうやり取りを行うのかを記述していきます。ユースケース記述は定められたルールはありませんが、一般的なルールの内シンプルなルールで記述して行きます。

それでは記事を閲覧するために、ユーザーはまず何をするでしょうか。

ユーザーはブログシステムにアクセスする。

このレベルで記述していきます。 なお、ユースケースシナリオは「誰が何をした」という形式で記述していきます。 次に、ブログシステムにアクセスした後は誰が何をするのか、それではその次は、と記述していきます。

以下のようになりました。

1. ユーザーはブログシステムにアクセスする。
2. システムはブログの記事一覧を表示する。
3. ユーザーは見たい記事の「もっと見る」リンクを押下する。
4. システムは選択された記事の詳細を表示する。

   

ユースケースシナリオに代替フローを記述する

基本的なユースケースシナリオは記述しましたが、これで完成とはなりません。 例えばユーザーがブログを見ようとアクセスして来た時に、記事がまだ全くなかったらどうしたら良いのでしょう。 そういった例外的なシナリオを記述していません。例外的なシナリオを記述するには代替フローと呼ばれるものを記述します。

それでは「記事を閲覧する」ユースケースシナリオに代替フローを記述します。

■ 基本フロー
1. ユーザーはブログシステムにアクセスする。
2. システムはブログの記事一覧を表示する。(ex-1
3. ユーザーは見たい記事の「もっと見る」リンクを押下する。
4. システムは選択された記事の詳細を表示する。(ex-2

■ 代替フロー
ex-1) 記事が1件もなかった場合
1. システムは登録されている記事がない旨を表示する。
2. このユースケースを終了する。

ex-2) 選択された記事が削除されていた場合
1. システムは選択した記事は削除された可能性がある旨を表示する。
2. このユースケースを終了する。

   

ユースケースシナリオにシナリオに乗らない部分を追記する

ユースケースシナリオは出来ましたが、作成している途中で気づいた点があります。 それは記事が100件、1,000件と増えていった場合に、どうするかという事です。

100件ならまだ許されるかも知れませんが、1,000件を一度に一覧として表示するというわけにはいきません。というわけで常識的に考えて20件ごとにページを分けるという方法を取りたいと思います。

また一覧に表示する順番は、記事が登録された日時が新しいものから順にすることにします。

ユースケース記述には定められたルールがないのをいいことに、これらを記述しておきます。

■ 基本フロー
1. ユーザーはブログシステムにアクセスする。
2. システムはブログの記事一覧を表示する。(ex-1
3. ユーザーは見たい記事の「もっと見る」リンクを押下する。
4. システムは選択された記事の詳細を表示する。(ex-2

■ 代替フロー
ex-1) 記事が1件もなかった場合
1. システムは登録されている記事がない旨を表示する。
2. このユースケースを終了する。

ex-2) 選択された記事が削除されていた場合
1. システムは選択した記事は削除された可能性がある旨を表示する。
2. このユースケースを終了する。

■付帯事項
・一覧は登録日時順が新しいものから順に表示する。
・一覧に一度に表示する記事の数は20件。
・一覧に表示している記事より古い記事が存在する場合「古い記事」リンクが表示される。
 「古い記事」を押すと表示している記事より古い20件までの記事が表示される。
・一覧に表示している記事より新しい記事が存在する場合「新しい記事」リンクが表示される。
 「新しい記事」を押すと表示している記事より新しい20件までの記事が表示される。

以上です。 次回はテストを作成したいと思います。

ブログシステムを作りながらRailsを学ぶ(7) ユースケースを記述し機能を明確にする

Turnipの記述形式

前回、Turnipを導入しました。 TurnipはRSpecを拡張したものであると紹介しました。

そのRSpechttp://rspec.info/Born under the banner of Behaviour-Driven Developmentとありますから、BDD(ふるまい駆動型開発)のためのツールと言ってよいでしょう。

つまり、TurnipはBDDを自然言語に近い形式で記述できるフレームワークと言えます。

単純な記述書式は以下のような感じです。 これ以外にも「かつ」や「しかし」が使用できます。

# encoding: utf-8
# language: ja
機能: 機能名
 シナリオ: シナリオ名
  前提 前提条件(ここからコロンが要らない)
  もし ○○した、○○された
  ならば  ○○となっていること

早速書いてみようと思ったのですが、手が止まりました。 「機能とは何ぞや」と

「機能」には何を書くべきか。

この機能ですが、単純に「ブログ一覧機能」とか「ログイン機能」とかで良いんでしょうか。間違いではないのかも知れませんが、「ふるまい」には当てはまりません。 シナリオも書かないといけないことから、ユースケースにすれば丁度良いんじゃないかと思い至りました。 ですので、今回はユースケースでやってみることにします。 他に何か良い粒度をご存知の型は、是非Twitterで教えて頂けるとありがたいです。

ユースケース図とは何か

ユースケースを洗い出すためにユースケース図を記述します。 ユースケース図とは「誰(どんな人)」が「何をするのか(何をしたいのか)」を表した図です。 「誰(どんな人)」をアクター、「何をするのか(何をしたいのか)」をユースケースと呼びます。 アクターには外部システムのような人以外のものを記述することも出来ます。

ユースケースには単純に「何をするのか」ではなく、「何をしたいのか」を意識することです。ユースケース図ではアクターが達成したい目的を記述するのが好ましいですから、「何をしたいのか」を意識することによって、例えば「ログインをする」というユースケースは記述しないという事が分かると思います。

しかし「ログインをする」は重要な機能ですから記述しておきたいということもあると思います。そういう場合はメインとなるユースケースの包含という形で記述すると良いでしょう。

ユースケース図を記述してみた

今回はastah*さんのツールを使用して作成しています。 簡単なブログシステムですから、以下のようなことが出来ることを目的に作成していきます。

f:id:wataruuu:20131011191106p:plain

     

最後に

今回はこれで終わりますが、ユースケース図をみると分かるように、非常に粒度が大きいです。 ユースケースとScrumのユーザーストーリーでは何が違うのかと思われると思いますが、その粒度が違います。ユーザーストーリーは受入テストが記述可能となりますが、ユースケースの粒度では大きすぎて不可能です。

これは全くの私見ですが、ユースケースにユーザーストーリーが含まれているとして、ユースケース図を書き、スクラムのユーザーストーリーをBDDのテストに落としこんでいくとハッピーになれるんじゃないかと思います。

CocoaPodsとは何か知るために訳してみた

CocoaPodsをちゃんと使うために、https://github.com/CocoaPods/CocoaPods を訳して理解を深めようと思います。

README


CocoaPodsは、Xcodeプロジェクトのライブラリの依存関係を管理するものです。

1つの簡単なテキストファイルでプロジェクトの依存関係を指定できます。 CocoaPodsは、依存関係のあるソースコードを取得し、プロジェクトを構築するXcodeワークスペースを作成し維持することで、ライブラリ間の依存関係を解決します。

最終的な目標は、集中的なエコシステムを作成することによって、サードパーティオープンソースライブラリを見つけやすくしたり、関係性を改善することです。

CocoaPodsをインストールしたり更新するのはとても簡単です。 Installation guide Getting started guideを是非見て下さい。 簡単な概要のためCocoaPodsの使用についてNSScreencastエピソードを参照してください。 概要については、NSScreencastエピソードのusing CocoaPodsを参照してください。


using CocoaPodsは動画なので、次はGetting started guideを見てみたいと思います。

Getting started


検索する

Podsの検索コマンドに名前か説明使ってcocoapods.orgから名前か説明を でポッドのコマンドライン検索のいずれかからポッドを検索することができます。

$ pod search json

(省略)

 

Podfileを作る

お気に入りの依存関係を見つけたら、Podfileを作成できます。 Podfileは通常、プロジェクトと同じディレクトリに作成します。 ここでPodfileとそのDSLについてもっと知ることができます。

(省略)

 

プロジェクトを統合する

CocoaPodsをプロジェクトに統合するにはそのディレクトリで、以下のコマンドを実行します。

$ pod install

プロジェクトファイルではなくXcodeワークスペースを開いて作業をして下さい。

(省略)

 

プロジェクトを更新する

Podfileに加えた変更を反映させるか、Podsフォルダのバージョン管理下にないプロジェクトに、bootstrapをインストールするには、次のコマンドを実行します。

$ pod install

pod installでは、新しいバージョンが利用可能であっても更新しません。 更新するためには次のコマンドを使用します。

$ pod update

これで、新しい依存関係をインストールする時に起きうるアップデートに関する問題を回避することができます。

 

 

新しく仕様を追加する

CocoaPods用のPodを持っていないライブラリもありますが、幸いにもPodは簡単に作成することが出来ます。

$ pod spec create Peanuts
<<Peanuts.podspecを編集>>
$ pod spec lint Peanuts.podspec

作ったらチケットを作成してPodをアップロード出来ます。 もしくはGitに慣れている場合は、CocoaPods specsリポジトリをforkしてpullリクエストを送ることが出来ます。 貢献してくれると大変うれしいです!

Pod specificationなしで任意のライブラリを使用する他の方法が幾つかありますが、それはSSCatalog exampleで見られます。


こんな感じでしょうか。