コード日進月歩

しんくうの技術的な小話、メモ、つれづれ、など

Rubyのraiseはエラーの指定を省略すると直前の例外を再度raiseさせる

知らなかった仕様

検証した環境

$ ruby -v
ruby 3.0.1p64 (2021-04-05 revision 0fb782ee38) [x86_64-darwin19]

出典

例外を発生させます。第一の形式(引用注:raise のみの記述のこと)では直前の例外を再発生させます。 - 制御構造 (Ruby 3.1 リファレンスマニュアル)

というようになっているので、raiseは引数を省略させると同じエラーを発生させる

実例

raiseの直後にraiseを呼ぶというのはrescue句以外だとつかわない、もとよりできないと思うのでrescueの場合の例を記述する。

以下の内容で test.rb をつくる

def demo_raise(happen_exception)
  raise StandardError, "これはエラーです" if happen_exception
  return true
end

begin
  demo_raise(true)
rescue
  p "catch exception"
  raise
end

これを実行すると以下のようになる

$  ruby test.rb
"catch exception"
test.rb:2:in `demo_raise': これはエラーです (StandardError)
        from test.rb:7:in `<main>'

raiseには何も指定していないのに直前のエラーを出している。ただし ensure や ブロックの外だと拾ってもらえないので気をつける

関連リンク

『ソフトウェア品質を高める開発者テスト 改訂版 アジャイル時代の実践的・効率的でスムーズなテストのやり方』を読み終わったよメモ

下記の本を買ってサッと読んだのでメモです

買った経緯

下記の記事でアジャイルなテストに関して語られており、メインスピーカーの方が新しく書籍を出されていたので気になり購入してみた。

logmi.jp

所感

品質のチェックを最後に寄せない、先にやる

買った動機の部分で紹介したお話でも主張されている内容ですが、この書籍で特に主張されている部分としては主に以下の点だと私は感じました。

  • バグの検出をシステム開発の最後の工程に寄せないで前半の工程でも検知していく(シフトレフト)
  • 単体テストをしやすいコードを下記、なるべく増やす
  • 単体テストもすべてやろうとしてない、抑えるべきところを抑える(HotSpot/C1網羅)
  • そもそも複雑にしない

従来からテストコードを重きにおく考え方に親しんできた開発者には馴染みのある部分もありますが、品質管理の分野の観点からも語られているのはよかったです。

新たな観点

「テストコードは書くべきである」「テストコードは後半のテスト作業の圧縮に寄与する」という部分や、テストコードの書き方一般論は割と他の書籍などで語られている部分でもあるのですが、こちらは著者の経験則と2000年代までのソフトウェアテストの文献の内容がアレンジされており、他の書籍ではあまり見たことのない観点もいくつかありました。自分が深堀りをしたほうがいいなと思ったのは以下のトピックです。

  • HotSpot
  • C0網羅/C1網羅
  • McCabe数(循環的複雑度)の指標

その他気になったこと

経験値がアレンジされた書籍なので、かなり経験談ベースの話が多いのですが書きっぷりがかなり口語調かつ読み手によっては不快感を感じることも多い文体なので、万人にオススメできるような感じではありませんでした。

ただ、筆者のかたの経験値と引用書籍の情報はおそらく他にあまりないものだと思いますし、主張自体も理解できる部分が多いものだったので私個人としては大変学びが多かったですし、純粋なテストケースを作ることに対する対策の解として知見を得ることができました。

また、この記事を読む前にtexta.fm第9回SideShowのテストに関する回を聞いており、チェッキングや探索的テストに関しての知見を聞いて理解度が高まったので、合わせて聞くと非常にいいかなと思いました。

関連リンク

中二日、中三日など中○日という表現が表す日程に関してざっくりまとめる

なかふつか、なかみっかなどと表現するがググりにくい言葉なのでざっとまとめる

中○日とは

日単位のアクションにおいて、事象を行ってから結果が発生するまでの間にかかる日数を示している。始端の日と終端の日を除いてかかる日数。

例えば「5/4から中3日かかる」という話だと5/8に結果が届くということを示す。図解すると以下のイメージ

主に使われる場面

  • スポーツ
  • 運送

でよく使われる傾向がある。特に運送などの場合は営業日の概念がここに入るので、ややこしくなるが基本的は間に入る日数というところを起点に考える。

定義が曖昧なので確認したほうがいい

ただしこの中○日、スポーツの場合は概ね上記で述べた考え方で問題がないのだが、発送の場合は到着が終端の日にあたるので発送する日自体は中○日の中に含まれるケースもあれば、そうでないケースもある様子なので不安な場合は確認を行ったほうがよさそう。

参考サイト

時間がないんだよね…という断り文句が頻出したときに見たいスライド『「時間がない」症候群、その傾向と対策』

スライド回顧録です。

対象のスライド

speakerdeck.com

みどころ

「時間がないからやれない」という話になったときに文字通り時間がない場合もあるが、実は純粋に「時間がない」だけではないのではないか?というところに切り込んでみた実例のスライド。自分自身も思い当たる節がある部分もあり、共感もできる部分も多い。またさまざまな状態がしっかりと言語化されているので、メンバーとしての立ち位置でも気づきがあり、リーディングする立場でも気づきのあるスライドです。

関連リンク

ユニバーサルデザインフォント(UDフォント)に関してざっくりまとめる

ユニバーサルデザインフォント(UDフォント)とは

フォントメーカーのイワタ社が提唱したもので定義としては以下のように書かれています。

UDフォントとは、ユニバーサルデザインの考えに基づいて作った文字(書体)をいいます。家電製品に表示する文字にも、年齢や障害の有無に関係なく、多くの人が少しでも見やすい文字を作ろうということで開発を始めました。 - UDフォント開発のきっかけと発売までの道のり(1/5):NICT

そのため何か仕様などがあるわけではなく、ユニバーサルデザインのコンセプトを汲んだフォント全般のことを指す。

イワタ社以外のUDフォント

2006年に「イワタUDフォント」がさきがけとなり、他の日本語書体を扱うフォントメーカーもUDのコンセプトに合わせたフォントをつくるようになり、2022年現在ではモリサワ社やモトヤ社、フォントワークス社などもUDフォントを作成している。

日本発祥の概念

もともと日本のイワタ社が提唱したものであるため、2022年時点では海外では認知が広くなく、日本国外ではまだ認知度の低い概念と思われる。(Googleトレンドで UD Font で比較しても検索ボリュームは日本のみある状況)

参考リンク

RubyのYARDにはRDocのような:nodoc:は存在しない

そもそもRDocの:nodoc:とは

Rubyに標準的に備わっているドキュメント生成のライブラリRDocには:nodoc:というオプションがある。これはどういうものかはドキュメントに記載がある。

指定した要素をドキュメントに含めません。 - library rdoc (Ruby 3.1 リファレンスマニュアル)

上記の通り「ドキュメントが存在しない」ということを示すものである。

YARDには対するものがない

YARDにはドキュメントの省略というものが存在しない、またデフォルトではYARDはpublicメソッドのみをドキュメント化する。

YARDにはなぜ:nodoc:が存在しないのか

互換性のある機能がありそうなものの、存在しないことに関してはYARDのReadmeに記載がある

YARD will by default only document code in your public visibility. You can document your protected and private code by adding --protected or --private to the option switches. In addition, you can add --no-private to also ignore any object that has the @private meta-tag. This is similar to RDoc's ":nodoc:" behaviour, though the distinction is important. RDoc implies that the object with :nodoc: would not be documented, whereas YARD still recommends documenting private objects for the private API (for maintainer/developer consumption). - GitHub - lsegal/yard: YARD is a Ruby Documentation tool. The Y stands for "Yay!"

上記の中にあるように

RDocは:nodoc:を持つオブジェクトはドキュメント化されないことを意味しますが、YARDはプライベートAPIのためのプライベートオブジェクトをドキュメント化することを推奨しています

という旨の一文があるので、原則としてドキュメントを書いてほしい意図から記述自体を用意していないということだと思われる。

参考サイト

RailsでRSpecを使う際にテストデータ用のファイルを置く場合はspec/fixtures/file配下が良さそう

CSVアップロード機能のテストなどをするときにテストデータを置きたいときのメモ

出典元

file fixture - RSpec Rails - RSpec - Relish

ドキュメントいわく

Rails 5 adds simple access to sample files called file fixtures.File fixtures are normal files stored in spec/fixtures/files by default.

ということで spec/fixtures/file というところに配置すれば file_fixture というメソッドから読み込みが可能なため、何か必要な場合は置くことを進めている。

file_fixtureとは

ActiveSupportでテスト用のメソッドが用意されており、そのうちの一つ。RSpecではその仕組みに乗ることを推奨している。そのためPureなRubyのコードでは使えない機能ではあるので気をつけること。

ActiveSupport::Testing::FileFixtures

参考サイト