正規表現間違い探しクイズ その2

正規表現間違い探しクイズシリーズです。

正規表現は単体テストを書いている場合でもバグを発見しづらいものです。 そのためレビューの時には注意深く見るようにしています。そんな中見つけた間違いのうち印象的だったものを紹介します。

問題編

仕様

Linkモデルにはurlを持ちます。urlは以下の条件を満たします。

• 入力必須
• 長さは256文字以下
• URLの形式を満たす必要がある
• プロトコルはhttpまたはhttpsのみ許可される
• ドメインはwww.example.comまたはblog.example.comのみ許可される

ソースコード

ソースコードです。 今回はRuby on Railsで実装します。

class Link < ApplicationRecord
  validates :url, presence: true, length: {maximum: 256}
  validate :valid_url

  private

  def valid_url
    return unless url

    if ! url?(url) then
      # URLの形式を満たしていない
      errors.add(:url, 'は有効なURLではありません。')
      return
    end

    if ! %r{\Ahttp(s)?://}.match?(url) then
      # httpまたはhttpsで始まっていない
      errors.add(:url, 'のプロトコルはhttpまたはhttpsのみ指定できます。')
    end

    if ! /((www)|(blog))\.example\.com/.match?(url) then
      # ドメインがwww.example.comまたはblog.example.comでない
      errors.add(:url, 'のドメインはwww.example.comまたはblog.example.comである必要があります。')
    end
  end

  def url?(url)
    # 今回の本題ではないので省略
  end
end

さて、上記ソースコードには明らかな間違いがあります。どのような間違いでしょうか。また、どのように修正するべきでしょうか。(ちなみに正規表現のはじめの\Aは文字列の先頭を指します。^と似ていますが、違いは参考のリンクを参照してください)

テスト

以下のテストはパスしています。

require 'rails_helper'

RSpec.describe Link, type: :model do
  describe '#url' do
    subject { link.errors[:url] }

    let(:link) { Link.new(params) }
    let(:params) { {url: url} }

    before do
      link.valid?
    end

    context '許可されるURLの場合' do
      context 'プロトコルがhttpの場合' do
        context 'ドメインがwww.example.comの場合' do
          let(:url) {'http://www.example.com/path/to/something'}
          it { is_expected.to be_blank}
        end
        context 'ドメインがblog.example.comの場合' do
          let(:url) {'http://blog.example.com/path/to/something'}
          it { is_expected.to be_blank}
        end
      end

      context 'プロトコルがhttpsの場合' do
        context 'ドメインがwww.example.comの場合' do
          let(:url) {'https://www.example.com/path/to/something'}
          it { is_expected.to be_blank}
        end
        context 'ドメインがblog.example.comの場合' do
          let(:url) {'https://blog.example.com/path/to/something'}
          it { is_expected.to be_blank}
        end
      end
    end

    context '許可されないURLの場合' do
      context '許可されないプロトコルの場合' do
        let(:url) {'ftp://www.example.com/path/to/something'}
        it { is_expected.to include('のプロトコルはhttpまたはhttpsのみ指定できます。')}
      end

      context '許可されないドメインの場合' do
        let(:url) {'http://www.hatenablog.com/path/to/something'}
        it { is_expected.to include('のドメインはwww.example.comまたはblog.example.comである必要があります。')}
      end
    end
  end
end

RSpec知らない人だと何書いてあるかわからないかと思いますが、重要な部分は、入力がhttp://www.example.com/path/to/somethingだとエラーが出なくて(be_blank)、入力がftp://www.example.com/path/to/somethingだとのプロトコルはhttpまたはhttpsのみ指定できます。というエラーが出るという部分です。

解答編

・

・

・

少し考えてから解答編を見てください

・

・

・

正規表現間違い探しクイズ その1

正規表現間違い探しクイズシリーズです。

正規表現のバグは単体テストを書いている場合でも発見しづらいものです。 そのためレビューの時には注意深く見るようにしています。そんな中見つけた間違いのうち印象的だったものを紹介します。

問題編

仕様

ユーザモデルはニックネームを持ちます。ニックネームは以下の条件を満たします。

• 入力必須
• 32文字以下
• 使用できる文字列は半角英数字と#$%&()-._

ソースコード

ソースコードです。 今回はRuby on Railsで実装します。

class User < ApplicationRecord
  validates :nickname, presence: true, length: { maximum: 32 },
                       format: { with: /\A[0-9a-zA-Z#$%&()-._]*\z/,
                                 message: 'には半角英数字と#$%&()-._のみ使用できます。' }
end

さて、上記ソースコードの正規表現(\A[0-9a-zA-Z#$%&()-._]*\z)には明らかな間違いがあります。どのような間違いでしょうか。また、どのように修正するべきでしょうか。(ちなみに正規表現のはじめの\Aは文字列の先頭、\zは文字列の末尾を指します。それぞれ^と$と似ていますが、違いは参考のリンクを参照してください)

テスト

以下のテストはパスしています。

require 'rails_helper'

RSpec.describe User, type: :model do
  describe '#nickname' do
    subject { user.errors[:nickname] }

    let(:user) { User.new(params) }
    let(:params) { {nickname: nickname} }

    before do
      user.valid?
    end

    context '許可される文字の場合' do
      context '英大文字小文字数字#$%&()-._' do
        let(:nickname) { 'ARZatz809(_#-$%.&)' }
        it { is_expected.to be_blank }
      end
    end

    context '許可されない文字の場合' do
      context '許可されていない文字"?"と"""が含まれている場合' do
        let(:nickname) { '?baerg"' }
        it { is_expected.to include('には半角英数字と#$%&()-._のみ使用できます。') }
      end
    end
  end
end

RSpec知らない人だと何書いてあるかわからないかと思いますが、重要な部分は、入力がARZatz809(_#-$%.&)だとエラーが出なくて(be_blank)、入力が?baerg"だとには半角英数字と#$%&()-._のみ使用できます。というエラーが出るという部分です。

解答編

・

・

・

少し考えてから解答編を見てください

・

・

・

ソフトウェアのテストを書くのが嫌になる瞬間 第5位

ソフトウェアのテストを書くのが嫌になる瞬間、今回は第5位です。

以下、単に”テスト”と書いた場合は、テストコードのことを指し、CIツールなどで自動実行されるものを指します。また、単に"コード"と書いた場合には、プロダクションコードを指します。 また、単体テストよりもエンドtoエンドのテストを厚く書く職場で働いています。

テストを書くのが嫌になる瞬間 第5位 : テストを書いたにも関わらずリリース後にバグが発見されたとき

辛い。

今回は漫画なしです。

テストを書くとバグが減ると思ってましたが、大して減りません。

バグが発生した原因としては、大きく分けると

• 自動テストのケース漏れ
• 手動でしか確認できない部分の漏れ(副作用系)

に分けられます。

リリース後に発見される(大抵はユーザ問い合わせで発覚する)バグで多いのは、"手動でしか確認できない部分の漏れ(副作用系)"です。このバグは自動テスト導入しても(当然ながら)一向に減ることはありません。

手動でしか確認できない部分の漏れ(副作用系)の具体的な内容としては、以下のようなものです。

• ファイルの書き出しが正しくされていない
• 他のAPIに通知されるはずが通知されていない
• メールが送られるはずが送られていない
• 親子関係のあるデータで、親を削除した時に子のデータも一緒に削除されるはずが、されていない

また、現在システムが複雑化していて、同じ機能を持ったアプリが複数ある状況で、片方で登録した内容がもう片方で正しく表示されない、などの問題もありました。

あとは、これはリリース前に気づいたことですが、運用ログが出力されていないということもありました。(参照する変数が間違っていて毎回ID:nullと出ていたり、文字列だけ組み立てて出力するコードを書き忘れていたり)。

個人的な感想ですが、自動テストを導入してそちらのテストに気を取られて手動でしか確認できないテストに手と気が回らなくなってる気がします。ツールの問題より人間の気力というのが難しいところです。

また、テストが通ること=バグがないこと、と思い、手動テストが必要だという意識がないメンバーもいて、頭を悩ませているところです。 テストを書くことによる恩恵も受けているので、テストを書かなくするという対応策も取れず。

第5位は以上です。その他のソフトウェアのテストを書くのが嫌になる瞬間は以下にまとめています。

yucatio.hatenablog.com

テスト駆動開発 [ Kent Beck ] 価格：3024円（税込、送料無料) (2018/12/31時点) 楽天で購入

ソフトウェアのテストを書くのが嫌になる瞬間 第4位

ソフトウェアのテストを書くのが嫌になる瞬間、今回は第4位です。

テストを書くのが嫌になる瞬間 第4位 : テストの文脈を見ないで落ちたテストのみ修正しているのをみたとき

今回は10コマ漫画でお送りします。

なお、以下単に”テスト”と書いた場合は、テストコードのことを指し、CIツールなどで自動実行されるものを指します。また、単に"コード"と書いた場合には、プロダクションコードを指します。 また、単体テストよりもエンドtoエンドのテストを厚く書く職場で働いています。

大体こうなるよね。

とにかく落ちたテストしか見ないのです。落ちたテストが書いてあるファイルは見てほしいし、少なくとも前後のテストケースくらいは確認してもらいたいものですが、見ないのです。ちゃんと元のテストコードには

説明	値	期待値
最小値 - 1	2	エラーが出る
最小値	3	登録できる
最大値	10	登録できる
最大値 + 1	11	エラーが出る

のように説明も書いてあるんですよ(上記だと期待値が適当ですが実際はちゃんと書いてあります)。全然読まれてない。

念のため書いておくと、下記のように直すのが正しいです。

説明	値	期待値
最小値 - 1	2	エラーが出る
最小値	3	登録できる
最大値	20	登録できる
最大値 + 1	21	エラーが出る

上記漫画の重症例はソフトウェアのテストを書くのが嫌になる瞬間 第1位と同じメンタリティですね。とにかくテストが通ればよいという考えのようです。

誰ですかテストは仕様書だと言ったのは。修正漏れたままマージされてしまったら、

説明	値	期待値
最小値 - 1	2	エラーが出る
最小値	3	登録できる
最大値	10	登録できる
最大値 + 1	21	エラーが出る

もしくは

説明	値	期待値
最小値 - 1	2	エラーが出る
最小値	3	登録できる
最大値	10	登録できる
最大値 + 1	11	登録できる

になりますよ。これ、"仕様分からないからソース見なきゃわかんない"に陥るパターンではないですか。

仕様変更での修正漏れは、レビューでもうっかりすると見逃すパターンです。書き換えられた部分は差分に出てくるのですが、書き換え忘れた部分は差分として出てこないからです。

とにかく私の周りでこのパターン多すぎてレビュー来るたびにげんなりします。どうすればよいのですか。教えてえらいひと。

第4位は以上です。その他のソフトウェアのテストを書くのが嫌になる瞬間は以下にまとめています。

yucatio.hatenablog.com

テスト駆動開発 [ Kent Beck ] 価格：3024円（税込、送料無料) (2018/12/28時点) 楽天で購入

ソフトウェアのテストを書くのが嫌になる瞬間 第3位

ソフトウェアのテストを書くのが嫌になる瞬間、今回は第3位です。

テストを書くのが嫌になる瞬間 第3位 : コードもテストも間違っているのをみたとき

今回は7コマ漫画2本でお送りします。

なお、以下単に”テスト”と書いた場合は、テストコードのことを指し、CIツールなどで自動実行されるものを指します。また、単に"コード"と書いた場合には、プロダクションコードを指します。 また、単体テストよりもエンドtoエンドのテストを厚く書く職場で働いています。

ケース1

あると思います。

人間だからミスはします。レビューに出す時点でバグがないことを求めてもしょうがないです。 ただ、直す手間が2重にかかることを考えると悲しい気持ちになります。

ケース2

ないと思います。実際にあった話ですが(コード間違っていて項目Fが出力されていなかった)。

テストケース作成の理想と現実

理想としては、テストもコードも仕様から作成するのが望ましいのです。

しかし、しばしばコードからテストケースの期待値を作成する例が見られます。

1人の人間がコードとテストを作成すると、仕様を勘違いしたままコードとテストを作成してしまうケースが発生しやすいです。コードを書いた後にテストを書くなら、もう一度新たな気持ちで仕様を読んでほしいですが、それが難しいことは想像に難くないです。

ところでTDDはこうだと思うのですが、

仕様からテストを作成する時に仕様を勘違いしてしまったらその勘違いに気づくのは結構後のフェーズだと思うのですがどうしているのでしょうか。

TDDは個人開発(仕様を作る人とテスト書く人が同一人物)か、ビジネスの仕様に左右されない部分(共通で使用される関数など)をテストする時に有用だとは思いますが、仕様を作る人とテストを書く人が別の場合、バグを防ぐという目的の達成はあまり期待しないほうがよい気がします。TDDを職場でやったことがないので想像ですが。

第3位は以上です。その他のソフトウェアのテストを書くのが嫌になる瞬間は以下にまとめています。

yucatio.hatenablog.com

テスト駆動開発 [ Kent Beck ] 価格：3024円（税込、送料無料) (2018/12/26時点) 楽天で購入

ソフトウェアのテストを書くのが嫌になる瞬間 第2位

前回に引き続き今回は第2位です。前回の記事はこちら↓

yucatio.hatenablog.com

テストを書くのが嫌になる瞬間 第2位 : 開発中に仕様が変わったとき

今回も11コマ漫画でお送りします。

なお、以下単に”テスト”と書いた場合は、テストコードのことを指し、CIツールなどで自動実行されるものを指します。 また、単に"コード"と書いた場合には、プロダクションコードを指します。 また、単体テストよりもイエンドtoエンドのテストを厚く書く職場で働いています。

あるあるではないでしょうか。実際にはもっとぐだぐだ説明してます。 (ちなみにCさんは仕様を決めたり他部署とのやりとりをしたりスケジュールを管理したりする役割の人です。)

コードの変更が数行でもテストの変更や追加が大幅になることがあります。特に1つのvalidationをするためのパラメータが3つや4つになってくると、単純に組み合わせぶんのテストをすると膨大な数になります。通常、全ての組み合わせぶんのテストをする必要はないので、どの組み合わせをテストするのか考えますが、これには時間が必要です。できているぶんのテストに追加しようと頑張りますが、大抵は1から作り直した方が早かったりします。 (ちなみに、すでに書いたテストを生かそうとして、テスト落ちたら期待値を書き換えるという手法をとると、期待値を検証せずに書き換えてミスに気づかないことが多いので絶対にやめとけ。)

ソースコードの変更が少ないので、プログラムを書く人以外にはテストの変更も少しであると思われるようです。毎回どうやったら分かってもらえるか苦心しています。

このように途中で仕様が追加されるのはプロジェクトの開始時にある程度予告されている(仕様が変わるかもと言われている)ことがほとんどですが、変わらないこともあるので進められるところまで進めてしまわなければなりません。

仕様が固まってから動きたいところですが、いろいろな部署が関わっている以上動かせるところは動かしてしまった方が良かったりするんですよね。理想的にはいかないものです。

こういうことが起こるので、TDDなどのテストを先に(または同時に)書く、という手法には、会社での開発には手が出しにくいと感じています。(個人での開発や少人数での開発には向くかもしれませんが)

第2位は以上です。ソフトウェアのテストを書くのが嫌になる瞬間は以下にまとめています。

yucatio.hatenablog.com

テスト駆動開発 [ Kent Beck ] 価格：3024円（税込、送料無料) (2018/12/22時点) 楽天で購入

ソフトウェアのテストを書くのが嫌になる瞬間 第1位

昔々、上級エンジニアのNさんは私に言いました。yucatioさん、テストはちゃんと書きましょう、と。 時は流れ、チームにテストを書く習慣ができました。めでたしめでたし。テストを書けば変更の影響がすぐに分かるので安全にリファクタリングができます。

でもなぜでしょう、たまにもうテスト書くのは嫌だという気持ちに襲われるのは。 そこでそんな気持ちになる瞬間をランキング形式にしました。

なお、以下単に”テスト”と書いた場合は、テストコードのことを指し、CIツールなどで自動実行されるものを指します。 また、単体テストよりもエンドtoエンドのテストを厚く書く職場で働いています。

テストを書くのが嫌になる瞬間 第1位 : テストを通すために期待値が上書きされたとき

ちょっとタイトルがわかりにくいので、10コマ漫画でお送りします。

(実体験を基にしています。)

これには参りました。テストを書く目的の1つとして、デグレを防ぐというものがありますが、完全に無効化されました。テスト書くのは面倒だし時間もかかります。それでもテストを書くのは、将来的にコードが変更されても動作が変わらないことを保証するためです。しかし、期待値を実行した結果で書き換えられてしまっては保証も何もありません(泣)。

この時は元のテストコードを書いた人(Aさん)がレビューしたから気づいたものの、Aさんがいなかったらきっとそのままマージされていたことでしょう。テストコードはプロダクションコードよりも読むのが面倒なことが多いので、注意して見ててても見逃してしまうことがあるので。

分かってはいます、Bさんのような人はごく一部だということは。しかし一度でもこのようなことをされるとテストを書いている最中、”テストを書いていてもどうせ間違った結果で上書きされるのではないか”、”それならテストを書かない方が良いのではないか”という極端な思考になってしまいます。もうトラウマですね。

おわりに

上級エンジニアの人たちは、テスト書け書けいう前に、自分が書いたテストが、間違った値で書き換えられている経験をしてほしいです。

現場からは以上です！

注) だからといっってテストを書かないという選択肢は自分にはないです！

2位以下は以下のカテゴリページからどうぞ。

yucatio.hatenablog.com

エンジニアの知的生産術 効率的に学び、整理し、アウトプットする （WEB＋DB　PRESS　plusシリーズ） [ 西尾泰和 ] 価格：2678円（税込、送料無料) (2018/12/20時点) 楽天で購入