保守しやすく変化に強いソフトウェアを支える柱 自動テストとテスト駆動開発、その全体像 ～Software Design 2022年3月号「そろそろはじめるテスト駆動開発」より | gihyo.jp
保守しやすく変化に強いソフトウェアを支える柱 自動テストとテスト駆動開発、その全体像 ～Software Design 2022年3月号「そろそろはじめるテスト駆動開発」より 今回、Software Design 2022年3月号 第2特集「そろそろはじめるテスト駆動開発 JavaScriptでテストファーストに挑戦」の第1章「保守しやすく変化に強いソフトウェアを支える柱 自動テストとテスト駆動開発、その全体像」を本サイトに掲載します。第2章以降については、本誌『Software Design 2022年3月号』電子版（Gihyo Digital Publishing、Amazon Kindle）をご購読いただければ幸いです。 第1章では、混同されることの多い自動テスト関係の概念を、自動テスト、テストファースト、テスト駆動開発の3つの段階に分け、それぞれの効果や注意点を説明します。ソフ
テストコードを書き始める前に考えるべきテストの話（2021年版） #scrumosaka / scrum_fest_osaka_2021
以下のイベントの投影資料です。 https://confengine.com/conferences/scrum-fest-osaka-2021/proposal/15337 お問い合わせは https://twitter.com/nihonbuson まで。 【発表資料中のURL】 P…
90. テストの目的 その② - テスターちゃん【4コマ漫画】
90. テストの目的 その② 欠陥や故障を発見し、ソフトウェアの品質が不適切になるリスクレベルを軽減する 「バグの発見」と書いたけど、シラバスに書かれている文章は上記の通り。 バグを見つけて、それを修正することで市場に出たときのリスクを軽減することができます。 「おいおい、見つけまくって全部直すのかよ！？」みたいに言う人もいるけど、これはまた別の回の「ステークホルダーへの意思決定のための情報提供」の話でやろうとも考えています。 先出しすると、見つけたバグについては「こういうリスクがあるよ」ということがわかるわけです。 そのうえで、どこまでリスクを許容するのかという考え方もあります。 「これだと大きなリスクはないし、次のスプリントで修正」ってことも全然ありなワケです。 けど例えばカーナビみたいな市場に出た後直せないやつだと、次、がなかったりもします。 ユニットテスト、統合（結合）テスト、シス
【Laravel】テストを書くときによく使うコード集 | Public Constructor
はじめに この記事は Laravel #2 Advent Calendar 2018 の14日目の記事です。 内容 今回はLaravelでテストコードを書く際に、普段使っている処理をまとめてみました。 LaravelにはHTTPリクエストのテストとして、Featureテストがあります。 Laravel is a PHP web application framework with expressive, elegant syntax. We’ve already laid the foundation — freeing you to create without sweating the small... 自分はFeatureテストから書き始めることが多いため、この記事の内容がFeatureテスト関連寄りになっているかもしれませんが、テスト周りで何か思いついたら更新していきたいと思います
リファクタリングの際に注意すべきこと | プログラマが知るべき97のこと
リファクタリングの際に注意すべきこと著者: Rajith Attapattu 私達プログラマには必ず、既存のコードの「リファクタリング」が必要になる時がやってきます。ただ、リファクタリングをする前にいくつか考えてほしいことがあります。次に書くようなことに注意すれば、自分を含め、開発に関わる全ての人の時間と労力を大幅に節約できるでしょう。 リファクタリングするにあたってはじめにすべきことは、既存のコードベースと、そのコードに対して書かれたテストコードの洗い直しです。具体的に、現状での良い点、悪い点、強み、弱みを1つずつ確認していきます。これは、良い点、強みを残しながら、悪い点、弱みを克服することにつながります。既存のシステムに手を加えれば、必ず元より良い物になるはずと考えがちですが、実は何も良くならないこともあるし、もとより悪くなることもあり得るのです。既存のコード、テストを十分に検証しなけ
エンジニアはつらいよ。ミーム動画で遊ぶエンジニアたち - 中華IT最新事情
ネット上では、誰がオリジナルの作者なのかもはやわからなくなっているミーム画像、ミームGIFが出回っている。エンジニアたちは、このようなミームを拡散するのが大好きで、知乎などのQ&Aサイトに、そのようなミームを集めたまとめ記事が投稿されることがある。 誰の著作物かもはやわからなくなっているミーム ネット上にはミーム画像、ミーム動画が存在している。元々は誰かの著作物なのだろうが、改変されることを繰り返して、もはや原著作者が誰だかわからなくなっているような画像、動画だ。あるいは原著作者が、勝手に二次利用されることを容認、黙認しているものだ。 ミームとは遺伝子に対応するものとして、遺伝学者リチャード・ドーキンスが作った言葉。文化も遺伝子と同じように、模倣を繰り返しながら継承されていくというものだ。ミームは、ミミック（模倣）、メモリー（記憶）などの言葉から作った言葉だという。 エンジニアたちは自虐的
「5人でユーザテストすればユーザビリティ上の問題のうち85%が見つかる」の元ネタ論文を解説する｜Mikio Kiura / ANKR DESIGN
Webサービスやアプリなど開発や運用に関わっている方であれば、こんなことを耳にしたことがあるのでは無いでしょうか？ 5人でテストを行えば、ユーザビリティ上の問題のうち85%を発見できるこれらは業界的にはある意味で常識ですが、色々話を聞いてみると、この常識の「出処」あるいは「根拠」ってあんまり知られていないようなのです。 もちろん、ちょっと知識のある人であれば、ユーザビリティ業界の第一人者であるヤコブ・ニールセン博士が提唱したというところまでは知識として知っているでしょう。しかしながら、その元ネタとなった論文を実際に読んだ人、あるいは85%という数字の根拠やその条件について理解されている方はどの程度居るのでしょうか。 ということで本記事では「ユーザテストは5人で85%」の元ネタである下記の論文について、解説、と言うとちょっと大げさかもですが、概要を紹介してみたいと思います。願わくば、この記事
疑似個人情報データ生成サービス
疑似個人情報とは、主にアプリケーションの開発／試験の際のテストデータとしての使用を目的とした架空の個人情報データです。 個人情報保護法の施行により、本物の個人情報を目的外であるテストデータとして使用することはできなくなっています。 また個人情報の漏洩が社会問題となっている今、「本物の個人情報」をテストデータのように別目的で使用することは、 情報漏洩の危険性が高まるだけでなく、企業としてのモラルも問われます。 このページは無料で、この擬似個人情報を生成することができる実験的サービスです。 生成したデータの商用利用も可能です。 下の「生成を開始する」ボタンを押して、条件を入力していくだけで簡単に個人情報データの生成を行うことができます。 作成したデータはMicrosoft Excel、CSVなどの形式でダウンロードすることができます。
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Shows - Event & Video Content
すごい名前生成器 - 創作・ゲームに使えるランダム人名ジェネレータ