モックは必要悪で、しないにこしたことはない - blog.8-p.info
Mockito や gomock が使いやすいせいか、単体テストというのはモックするものである、という思い込みがあるのか、人々がモックしすぎているのを時折みかける。 モックは必要悪で、しないにこしたことはない。外部の API サーバーとかはガンガン叩くわけにもいかないけれど、ファイル読み書きくらいは、実際にファイルを作ったり消したりしてしまっていい。/etc/passwd を消すとか、1GB のファイルを作るとかだと難しいかもしれないけれど、その場合でも、パスのプレフィックスを指定できるようにして、一時ディレクトリの中の etc/passwd を使うとか、ファイルサイズを指定できるようにするとか、逃げ道はいくつもある。そこを飛ばして「ファイル操作は一律モックしましょう」とか頑張りだすと辛いことになりがちだ。 モックの一番の問題は、本番とテストで違うコードが走ることで、これは自動テストの価値
プライベートメソッドのテストは書かないもの？ - t-wadaのブログ
この文章の背景 この文章はプライベートメソッドのテストを書くべきか否かに関する knsmr さんのご質問に対して 2013/03/13 に QA＠IT で回答したものです。残念ながらQA＠IT のサービス終了（2020/02/28）と共にアクセスできなくなってしまったため、運営を行っていたアイティメディア株式会社様、開発を行っていた永和システムマネジメント様、そして質問をされた knsmr さんに許可とご協力をいただき、当時の回答をサルベージしてブログに転載する運びとなりました。 プライベートメソッドのテストはよく議論になるテーマですので、当時の回答を再編集し、knsmr さんのご質問も含め、ご利用いただきやすいライセンス CC BY（クリエイティブ・コモンズ — 表示 4.0 国際 — CC BY 4.0） で公開いたします。 目次 この文章の背景 目次 knsmr さんのご質問 私の回
より良いコードレビューをするために気をつけていること | メルカリエンジニアリング
Merpay Advent Calendar 2019 の22日目は、メルペイスマート払いチーム/Backend Engineer の @oinume がお送りします。今日はコードレビューについて自分が普段から実践していることを書いてみたいと思います。 はじめに 世の中にはコードレビューをする時の観点については数多く共有されていますが、より良いコードレビューをするためにはどうするのが良いか、というHOWについてのノウハウはあまりシェアされていないような気がしています。そのため、今日は自分なりに心がけているコードレビューのやり方と、ついでに気をつけている観点について書きたいと思います。 Slackを閉じる (これが本当に一番大事だと思っているので最初に持ってきたのですが)私は極端に集中力がないため、SlackのDesktop通知が来るとついついそれが気になって見てしまいます。コードレビューの
機械学習のビジネス上の価値を「効果測定」して「数値評価」する方法 - 六本木で働くデータサイエンティストのブログ - 渋谷駅前で働くデータサイエンティストのブログ
(Image by Pixabay) 気が付けば、日本における第一次データサイエンティストブームから6年、人工知能ブーム開始から3年が経ったようです。意外と言っては何ですが、これまでのところ人工知能ブームも、そしてそれにブーストされた形で起こった第二次データサイエンティストブームも、まだまだ続くどころかどんどん加速していきそうな状況です。 なのですが、これだけ統計学や機械学習のような高度なデータ分析技術がビジネスの現場に浸透するようになった現在でも、なぜかあまり多く見かけないものがあります。それは「機械学習（もしくは自動化された統計分析）によるビジネス上の成果を数値として示したもの」。意外かもしれませんが、個人的な観測範囲では例えば「Deep Learningを導入したら〇〇がXX%向上した」みたいなリリースや記事を見かけることは、正直なところ思った以上に少ないように思われます。それでも第
テストレベルに「機能テスト」が入ると困る理由 - ブロッコリーのブログ
はじめに この記事は ソフトウェアテストの小ネタ Advent Calendar 2019 の3日目の記事です。 もはや、「小ネタ」という文量を遥かに超えてしまっている気もしますが、「機能テスト」という1つの単語に対しての小ネタということで…。*1 目次 はじめに 目次 この記事のきっかけ こんな記事がありました テストレベル テストタイプ 素朴な質問 「機能テスト」がテストレベルに入っていることによる弊害 理由1. 複数人の間で認識齟齬が発生してしまうため 理由2. 不足や重複が確認しづらいため 理由3. テストできるはずの粒度・タイミングでのテストができるように見えなくなってしまうため さらに発展した話 テストコンテナ テスト計画 テスコンチュートリアル（OPENクラス）にて… おわりに QA歴の浅い人の感想(Slackのスクショ) 開発者の感想 この記事のきっかけ こんな記事がありま
現在時刻が関わるユニットテストから、テスト容易性設計を学ぶ - t-wadaのブログ
この文章の背景について この文章はテスト容易性設計をテーマに 2013/11/26 に CodeIQ MAGAZINE に寄稿したものです。残念ながら CodeIQ のサービス終了と共にアクセスできなくなっていたため、旧 CodeIQ MAGAZINE 編集部の皆様に承諾いただき、当時の原稿を部分的に再編集しつつ、ライセンス CC BY（クリエイティブ・コモンズ — 表示 4.0 国際 — CC BY 4.0） で再公開いたしました。 旧 URL にいただいたブックマークとご意見はこちらです（これであなたもテスト駆動開発マスター！？和田卓人さんがテスト駆動開発問題を解答コード使いながら解説します～現在時刻が関わるテストから、テスト容易性設計を学ぶ #tdd｜CodeIQ MAGAZINE）。旧記事には本当に多くの反響をいただき、誠に感謝しております。 目次 この文章の背景について 目次 出
「FF6」の新たなバグを発売25年後に見つけたテスト技術者の腕前
1994年に発売された大人気ゲーム「ファイナルファンタジーVI（FF6）」（スーパーファミコン版）をやりこみ、2019年になっても未発見の「バグ」を見つけ出し続けている人がいる。ここ数年、熱心なゲームファンを何度も驚かせているのが、「エディ」のハンドルネームで知られるプレーヤーだ。必須のイベントをクリアせずに先に進める方法を見つけ出し、毎年のようにゲームクリアまでの「歩数」の最少記録を更新している。 本記事でいうバグとは、ゲーム開発者が意図していなかったと推測される仕様を含む。特別な操作をすると通常とは異なる挙動となり、いわゆる「裏技」が可能になる。 FF6スーパーファミコン版はスクウェア（現スクウェア・エニックス）が開発したロールプレイングゲーム（RPG）で、美しいグラフィック、ドラマチックなシナリオ、完成度の高いゲームシステムが好評を博し、全世界で約340万本の売り上げを記録した。人気
Takuto Wada on Twitter: "コードには How テストコードには What コミットログには Why コードコメントには Why not を書こうという話をした"
コードには How テストコードには What コミットログには Why コードコメントには Why not を書こうという話をした
ソフトウェア開発者がテスト技術の資格「JSTQB」のテキストを読んで感じたこと - こまぶろ
テスト技術についての資格である「JSTQB認定テスト技術者資格」のテキストを読んだ。読もうと思った理由は後述するが、ソフトウェア開発についての考えに別の光を当ててくれるいい体験になった。 ソフトウェアテスト教科書 JSTQB Foundation 第3版 作者: 大西建児,勝亦匡秀,佐々木方規,鈴木三紀夫,中野直樹,町田欣史,湯本剛,吉澤智美出版社/メーカー: 翔泳社発売日: 2011/11/12メディア: 単行本（ソフトカバー）購入: 5人 クリック: 85回この商品を含むブログ (12件) を見る なぜテストを学ぼうと思ったのか 僕は開発者、プログラマという自己認識をしており、現在の業務の中心はソースコードを書くことだ。また、普段勉強している事柄も、コードの書き方やプログラミング言語についてのものが中心になっている。 しかしながら、今回、テストの勉強をざっとでいいのでしておくべきだと思
13. ペアプロやテストの疑問とか、ソフトウェアエンジニアの育成とか | fukabori.fm
話したネタ ペアプロにおけるビギナーとベテランの組み合わせ3パターンについて ビギナーとビギナーの組み合わせで効果はあまり期待できない（チームビルディングでは意味がある） ベテランとベテランは、一番効果を発揮するペアである 意思決定をライブでできる重要性 設計上の妥協点をその場で合意できる ビギナーとベテランで、ビギナーはナビゲーターをするのか？ コードを書いてるところを見てもらうのは大事なプラクティス ベテランもプレッシャーを持ってコードを書ける 見られているだけでコードの質は高まる リアルタイムでないコードレビューがあるだけで、コードの質は高まる コードレビューのインフラに投資する 流しのペアプロ業をする中で、ドメイン知識がない状態でペアプロへ参加して価値をだせるか？ 一番の学びは教えることから発生する 相手から、相手自身の学びを引き出す チームの暗黙知を、暗黙知のまま伝える、強化して
アバターによる新時代コミュニケーション vmeets
vmeetsはカメラもアバターも使える安心・高機能のWeb会議ツールです。無料・登録不要・時間制限なしでいつでもどなたでもご利用頂けます
結合テストと呼ぶのをやめた話 - asterisc
はじめに 最近、意図的に「単体テスト」「結合テスト」という呼び方を避け、Google Testing Blogで紹介されてるTest Sizesによる分類（small / medium / large）に従った呼び方でテストを呼んでいる。 この分類方が自分の身の回りに徐々に浸透してきて、実際のチーム内のテスト戦略も一歩進んだ議論ができるようになってきたので、改めてまとめる。 ちなみにこの記事の話は手動で行われるテストではなく、自動テストを対象としているが本質はあまり変わらないと思う。 続き書きました。 akito0107.hatenablog.com 「単体テスト」「結合テスト」という呼び方について ソフトウェア開発に従事していれば必ず聞く言葉だと思う。改めて他のサイトから引用する形で定義をまとめておく。 単体テストとは *1 単体テストとは、プログラムを検証する作業の中でも、プログラムを
嫌われていたいい先生の話 - 糸魚川鋼二の個人ブログ
ツイッターで夏休みの自由研究ネタががやがやしていたので、思い出した。 中学の頃に出会ったT先生の話。 T先生は社会科の先生で、僕らの入学と同時に中学に赴任してきた先生だった。 初日からダジャレやギャグを飛ばしたそうで、入学早々「当たり」の先生と評判になった。T先生のクラスになっていた小学からの友人たちはみんな喜んでいた。僕の中学は福岡の普通の公立、近隣２つの小学校から来ていて、生徒の半分は入学時から顔見知りなのだ。情報はすぐに伝播する。 １年生の頃、僕はT先生と特に接点はなかった。担任の先生でもないし、社会の授業も別の先生に教わっていた。だからT先生は噂でしか聞くことはなく、へー面白い先生らしいなあ、いいなあって感じ。 それが、一年生が終わる頃にはT先生の評判は一変して「最悪」で固まっていた。 生徒からも保護者からもだ。 え、なんで？ あんなにみんな喜んでたじゃん、なんで……？ 友人らに理
テスト自動化の理論と技術と戦略：LINE Developer Meetup Tokyo #39 - Testing & Engineering - LINE ENGINEERING
テスト自動化の理論と技術と戦略：LINE Developer Meetup Tokyo #39 – Testing & Engineering By Hiroyuki Ito | 2018.07.09 2021.01.08LINE株式会社のSET（Software Engineer in Test）です。「SETタスクフォース」（以下「SETチーム」と表記）のリーダーとして、主にLINEプラットフォームのサーバーサイドで、テスト自動化を活用したプロダクト開発ライフサイクルの改善を立案・実施・主導しています。また、アジャイルコーチも兼務しています。 はじめに こんにちは。LINE株式会社のSET（Software Engineer in Test）の伊藤 宏幸（Hiroyuki Ito）です。 2018年6月27日（水）に、電気通信大学の西 康晴さん（以下「にしさん」と表記）をお招きして、「
構造を浮き彫りにするテスト
はじめに 今回はソフトウェアテストをソフトウェア開発の目的から2つに分類します。「構造を浮き彫りにするテスト」と「構造を決定するテスト」です。これは筆者独自の分類方法です。 これらは品質向上に対して相互補完的な関係にあり、それぞれのスキルの成長にも傾向があります。自身や組織に不足しているソフトウェアテストがどちらなのかを認識し、効率的に品質を向上させましょう。 今回は、まず「構造を浮き彫りにするテスト」の導入について解説します。 テストには2種類ある 効果的にソフトウェアテストを実践していくには、組織やプロダクトにとってのソフトウェアテスト自体を適切に構造設計することが必要です。その構造に従ってソフトウェアテストのスキルを組織的に成長させたり、その構造に従って各プロジェクトにおけるテスト戦略を位置づけたりしていきます。これらは個人にも組織にも納得感の高いことが重要です。 そういったソフトウ
フロントエンドの負債と向き合う - mizchi's blog
某所で書いたものを公開用に書き直したもの 前提 フロントエンドでTDDは難しい、というかほぼ不可能である。なぜなら事前に副作用をデータとして表現できるか不明だからだ。たとえばあなたのプロダクトの画面の何処かにボタンを追加するために、その内部表現を事前に思い浮かべることが可能だろうか？ react-redux などのFluxフレームワークは如何に副作用をアクションとして表現することで、テスト・デバッグのための情報を残すか、という視点で発展してきた側面がある。あの冗長なアクション定義は、全てデバッグのために書いていると言っても、過言ではない。それすら「Textは文字がある」といったトートロジーなデータになりがち。 フロントエンドの現実的な単体テストは、他の開発者のために、自分が書いたコードの要求を満たしているか検知する手段として、防衛的にテストアフターしておく。これぐらいしか現実的な手法がない
ペアプログラミングして気がついた新人プログラマの成長を阻害する悪習
最近、あまりプログラミングが得意でない人のサポートをする形で、長い時間にわたってペアプログラミングを行っている。そのなかで、気がついた悪い習慣と成長するための良い習慣というものをまとめてみる。 この記事のバックグラウンドとなる体系的知識が本になりました。 エンジニアリング組織論への招待 ～不確実性に向き合う思考と組織のリファクタリング あわせて読みたい 経営者マインドが足りない！vs. 現場に任せてくれない！の対立をなくすカードゲームをつくった話 新人プログラマに知ってもらいたいメソッドを読みやすく維持するいくつかの原則 新人プログラマに知っておいてもらいたい人類がオブジェクト指向を手に入れるまでの軌跡 ペアプログラミングして気がついた新人プログラマの成長を阻害する悪習 あきらめるにはまだ早い！ソースコードの品質向上に効果的なアプローチ 心理的安全性ガイドライン（あるいは権威勾配に関する一
JaSST’18 Tokyo A8クロージングパネル簡易まとめ – それはそれとして
JaSST’18 Tokyo Day2のクロージングパネルの書き殴りまとめ。 アジャイル・自動化時代のテストの現場のリアル モデレータ： 荻野恒太郎さん（楽天） パネリスト： John Miccoさん（Google） 天野祐介さん（サイボウズ） 松尾和昭さん（クックパッド） 山口鉄平さん（ヤフー） 自己紹介 コンテキストを合わせるためにサービスのデプロイ/リリース頻度を伝え合う 荻野さん1日数十回のデプロイ（テスト環境含む） リリースは1週間に数回 天野さん月1リリース（kintone） 1日数回のデプロイ 山口さんプロダクトによって差がある 多いところは1日数十回のデプロイ 2週間～1か月のリリース、デプロイもある テスト自動化はいま進めているところ デプロイ、リリースの自動化も進んでいる 松尾さんモバイルオートメーションに比重を置いている 検索・レシピ投稿でチーム分割している 1チーム
Rails で、Controller に定義されている action を一度に取得する方法はありますか？ - QA@IT
平素よりQA＠ITをご利用いただき、誠にありがとうございます。 QA＠ITは「質問や回答を『共有』し『編集』していくことでベストなQAを蓄積できる、ITエンジニアのための問題解決コミュニティー」として約7年間運営をしてきました。これまでサービスを続けることができたのは、QA＠ITのコンセプトに共感をいただき、適切な質問や回答をお寄せいただいた皆さまのご支援があったからこそと考えております。重ねて御礼申し上げます。 しかしながら、エンジニアの情報入手方法の多様化やQAサービス市場の状況、＠ITの今後のメディア運営方針などを検討した結果、2020年2月28日（金）15:00をもちましてQA＠ITのサービスを終了することにしました。 これまでご利用をいただきました皆さまには残念なお知らせとなり、誠に心苦しく思っております。何とぞ、ご理解をいただけますと幸いです。 QA＠ITの7年間で皆さまの知識
スマホマーケットの概要と、�マーケティングの失敗例と改善 （アナリティクス アソシエーション 特別セミナー）
プレゼンテーションのスライド資料を作る上で押さえておきたい基本をまとめました． 多分これがslideshare内で一番役に立つと思います． スライドの作り方を学んだことがない方、参考にどうぞ！ 2016.01.22 書籍発売 好評につき重版決定！！ http://book.impress.co.jp/books/1114101129 リニューアル増量版 http://www.slideshare.net/yutamorishige50/ss-41321443 2014.11.9アップロード！ 【連絡先等】 Yuta Morishige Webサイト: https://mocks.jp/ ※旧タイトル 【プレゼン】研究室発表のプレゼン資料の作り方【初心者用】
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
