ねこものがたり

いちにちいっぽ

自動化テストについて

覚書

  • .rspecを変更してテストの実行結果の画面をカスタマイズする

(例)

--format documentation

 自動化テスト

自動化テストは機能が正しく実装されたことを確認するためのもの。 「不安をなくす(確実に動くことを確認できる)」「実装を追加したり変更したりするときにも壊さないようにする(変更後に何か壊れたとしてもすぐに気づける)」などがテストのいいところだそうです。

とても大事そう、便利そうなのはよくわかるけど、自分で書けるようになるのはとても苦戦しています。でも、少しわかってきた気がします。(気のせいだったら悲しい)

テストのレイヤー

テスト 特徴
↑ユーザ システムテスト エンドトゥエンド、UI、遅い、壊れやすい
統合テスト 機能同士のつながり、ユニットテストのカバー
↓開発 ユニットテスト 局所的、早い、信頼性高い、設計開発

システムテスト

ユーザーの実際の動きを想定したテスト。要件通りになっているかを確認する。

統合テスト

機能同士やAPIなどの連携についてのテスト。単体では動いても連携するとバグが起きることもある。

ユニットテスト

modelやhelperの機能をテストする。 1つのテストで1つの機能のテストをする。

  • ハッピーパス:理想とする動作
  • 特殊ケース:特殊な条件、エッジケース
  • 例外:エラーが起こるとき
  • 流れとロジック:プログラムの流れや条件分岐
  • そのほか:他に必要なテストはないか

ユニットテスト→統合テスト→システムテストの順に書いていく。

テスト駆動開発の基本

流れ

  1. 失敗するテストを書く
  2. テストが通るように実装コードを書く
  3. リファクタリングする

テスト難しい

本を読んだりコードを見たり写したりする→できる気がする→やってみる→できない→本を読んだり・・・

をここ数日繰り返してるけど、自分こんな頭悪かったっけっていう気持ちが湧いてきて本当にたまらない感じ。(や、でも、確かに賢くはない)

でも書けるようになると楽しいらしいです。

毎日少しでもいいからやっていくしかない。 あと、もっとたくさん人のコードを見て回って、テストの考えかたも書き方も感覚的なものも掴んでいきたいです。

参考

Ruby on Rails チュートリアル:実例を使って Rails を学ぼう

Rails テスティングガイド | Rails ガイド

O'Reilly Japan - 初めての自動テスト

Everyday Rails… by Aaron Sumner et al. [Leanpub PDF/iPad/Kindle]

テスト自動化について、調べてみた - Qiita

OmniAuthのTwitter認証でつまずいたこと(2)

前回の続き。

残ってるエラーたくさんあるかと思っていたけど1個だけでした。 1個だけだったんだけど、その1個が本当にわからなくて辛かったです・・・

修正したのは/models/user.rb.

修正後

class User < ApplicationRecord
devise :database_authenticatable, :registerable,
         :recoverable, :rememberable, :trackable, :validatable,
         :omniauthable, omniauth_providers: %i[twitter]
  def self.from_omniauth(auth, singend_in_recource = nil)
    where(provider: auth.provider, uid: auth.uid).first_or_create do |user|
      user.email = auth.info.email || User.create_unique_email
      user.password = Devise.friendly_token[0, 20]
      user.name = auth.info.name
      user
    end
  end

  def self.create_unique_string
      SecureRandom.uuid
  end
    
  def self.create_unique_email
      User.create_unique_string + "@example.com"
  end
end

いわゆる写経

基本はgithubwiki、そこに載っていない箇所は人様のコードを写しました。

その結果「やりたいこと・やるべきことは理解できるんだけど、写したコードでうまく動かない時に何が違っているのか見当をつけられない」という罠というか沼というか、自業自得といえばそうなんだけど・・・という気持ちになる何かにはまっていました。

写経は「0から100まで全て一貫した(しかも全て正しく書けている)ところから完全に写経する」というのであれば、まずは全てを理解できてなくてもコードに慣れることだとかメリットはたくさんあると思います。

でもあちこちから切り貼りする場合、コードに一貫性がなかったり、抜けや重複があったりもするし、気をつけていないと書いた人の前提条件が違っていることもあるので、一層「どんな意図でこのコードが書かれているのか」って分かっておかないと写すメリットが減ってしまうなあと感じました。

でも、それが分かってたら自分でかける!とも思います笑

だから、「わからん・・・」という気持ちになっても粘って「なるほどこれか!」って分かったり、また「わからん・・・」となったりしながら(写経も含めて)そういうのを繰り返していくしかないのかな〜道は果てしないな〜という感じです。

人生達観しておいたほうがよさそうだ。

何を直したか

という訳で今回は他の人が書いた記事などを読んだり写したりをしていました。

書きたい事
  • Twitter認証ではメール情報が空になってしまう
  • メールが空の時ダミーアドレスを生成するメソッドを呼ぶようにする

これがやれればうまくいく、というのは理解はオーケーでした。

どう間違えていたか

RailsでDeviseとOmniAuthによるTwitter/FacebookのOAuth認証、および通常フォーム認証を併用して実装 | EasyRamble この記事を読みました。

そして写していたコード。

def self.find_for_twitter_oauth(auth, signed_in_resource=nil)
    user = User.where(:provider => auth.provider, :uid => auth.uid).first
    unless user
      user = User.create(name:     auth.info.nickname,
                         provider: auth.provider,
                         uid:      auth.uid,
                         email:    User.create_unique_email,
                         password: Devise.friendly_token[0,20]
                        )
    end
    user
  end
 
  # 通常サインアップ時のuid用、Twitter OAuth認証時のemail用にuuidな文字列を生成
  def self.create_unique_string
    SecureRandom.uuid
  end
 
  # twitterではemailを取得できないので、適当に一意のemailを生成
  def self.create_unique_email
    User.create_unique_string + "@example.com"
  end
end

こちらのコードでやろうとしている事 1. ツイッター認証する時にuser

#

上述のように、私はこの記事のこの部分だけこの記事を参考にし、その他の箇所はdeviseのgithubにあるwikiを基本にしていたので、矛盾が生じてしまいました。おそらくどちから一方だけであれば問題なく動いたんだろうと思います。