ユニットテストをGitHub CopilotとChatGPT使って書いてみたらやばかったです | DevelopersIO
GitHub Copilotとの単体テストがやばい。ChatGPTが書いてくれるテストもすごい。もうこれらがない時代には戻れないような気がします。 こんにちは。AWS事業本部コンサルティング部に所属している今泉（@bun76235104）です。 みなさんユニットテスト書いてますか？ 昨今AIがダミーデータを書いてくれたり、ユニットテストそのものを書いてくれたりと技術の進歩がすごいですね。 私はリファクタリングが好きですが、リファクタリングをする前に絶対に必要なもの。 そうテストですね。 今回私がテストを後回しにしてしまった以下のOSSについてGitHub CopilotとChatGPTのそれぞれの力を借りながら、テストを書いてみました ※ これは以前私が始めたプロジェクトであり、OSSとして公開されているので学習に使われても問題のないコードです。 なお、GitHub Copilotの料金や
ブロッキングバグ（ぶろっきんぐばぐ）
ソフトウェアテスト（注1）の作業あるいはプロジェクト全体の進行を妨害するバグ（注2）のこと。 ソフトウェアプログラムのテスト作業を行う際、ある機能がバグによって動作しないためにその機能に関連する機能も動作せず、テスト自体ができないことがある。 また、あるテストが失敗したためにそれに依存するテストも不能（無意味）になる場合もある。このとき、テスト不能状態を引き起こしている原因となるバグをブロッキングバグという。ブロッカーバグ、ブロッカー、リリースブロッカーともいう。 前提条件を満たさないためにテストケースが実行できないことを「ブロック」という。ブロッキングバグはブロックを引き起こすバグである。ブロック状態のテストケースが多ければ多いほど、テストカバレッジが下がるので、一般にブロッキングバグは緊急に対応する必要がある。
新人技術者のためのロジカル・シンキング入門（7） ―― 「ひたすら流すだけのテスト」にさよなら
【3】意外と難しい「単体テスト」，「結合テスト」の区別（1/2） 次に，「単体テスト」と「結合テスト」という分類の仕方について考えてみることにしましょう．冒頭の例でいうと，Gさんが担当しているモジュールの単体テストを終えたら，次の工程で全体の結合テストを実施することになります．単体テストから結合テストへという進め方は，一つ一つ部品を確実に組み立てる立場からすれば当たり前のことのように思えます．しかし，実際の開発ではこの「単体」と「結合」の区別はそれほど容易ではありません． 開発者の中には，「単体テストとは関数一つ一つに対して行うもの．それらの確認が終わって初めて結合テストができる」とやや教条主義的に考えている人もいます．また，結合テストはビッグバン・テスト（単体が終わったら全体を一気につなげる）以外考えず，段階的に結合していくことにはあまり関心のない人もいます．このような考え方が行き過ぎる
MC/DCによる現実的な網羅のススメ (PDF)
CESL Copyright CATS 2009 [2009 年 7 月 8 日]1 MC/DC による現実的な網羅のススメ 松本 充広† Modified condition/decision coverage（MC/DC）は，ソフトウェアのテスト網羅度として非 常に有効な指標である．テスト網羅度は，ソフトウェアテストにおいて，充分にテストした，と いう品質基準を定義する指標の一つであり，テスト網羅度を用いることで，ソフトウェア品質 を保持しながら，コストや時間が無制限に増大するのを避けることができる．MC/DC は，故 障が人命に係わる航空機ソフトウェアのテスト時に使用するテスト網羅度として，米国の航 空機産業の業界団体である RTCA が策定した DO-178B の中で開発された．MC/DC 開発 以前に存在したテスト網羅度は，様々な問題を持っていたが，これらの問題が MC/DC
[PDF]テスト技術者資格制度 JSTQB Foundation Level シラバス
テスト技術者資格制度 Foundation Level シラバス 日本語版 Version 2011.J01 International Software Testing Qualifications Board (翻訳 Japan Software Testing Qualifications Board) テスト技術者 資格制度 Foundation Level シラバス International Software Testing Qualifications Board ©InternationalSoftwareTestingQualificationsBoard VER2011 ©日 本 語 翻 訳 版JapanSoftwareTestingQualificationsBoardVersion2011.J01, 2/81 2011/03/30 著作権情報 この文書は出典を明らか
動的テストツールDT10 | ハートランド・データ株式会社
「動的テストツールDT10」は、グレーボックステストのためのツールです。プログラムを実行せずにパス解析やフロー解析を行う静的解析とは異なり、実際に実行されているプログラムの挙動を動的に解析します。 DT10なら、1度トレースするだけで、「不具合解析」「動的コードカバレッジ計測」「性能測定・パフォーマンス改善」を一気に解決。ソフトウェア開発の”効率化”と”品質の向上”を同時に実現します。 グレーボックステストとは ソフトウェアの外部要件に基づいたブラックボックステストと、ソフトウェアの内部構造および内部仕様に基づいたホワイトボックステストの中間的な位置づけの手法。ソフトウェアの内部パス、構造を知ったうえで、機能仕様から見たユーザー視点の動作テストを行う。設計やコードがどうなっているかを知ることによって、テストケースを削減し、より少ないテスト量でバグが出そうな箇所のテストを行うことができる。
さらに分かっておきたいトランジスタの種類 − ＠IT MONOist
ECサイトを題材にソフトウェア開発の全工程を学ぶ新シリーズ「イチから全部作ってみよう」がスタート。シリーズ第7回は、要求仕様フェーズで作り上げる正しい要求仕様書に向けた第一歩となる「ヒアリング」について解説します。
テストのめどい話
最初にめどい言い訳をせねばならぬ俺は江島氏ともきょん氏とも面識はないですが、お二人ともが俺のことを知ってることを俺も知ってる程度には狭い業界であり。どちらかに肩入れしたいわけではないです。喧嘩したいわけでもないです。普段あまりここでは言及しないですが俺は今の仕事としてはテストを書いたりテストを実施したりする係をしてノリクチをしのいでおり、いわばテストは本業ですので、テストに言及することは今現在の同僚に対して意図しない受け取られ方をする可能性があるので困るので、それもあって普段はここではあまりテストの話はしないわけだが、だからと言って沈黙を破ってテストの話をするのが同僚に対して含みがあるというわけでもないです。とはいえ俺は大学等で真面目にソフトウエア工学の講義を受講したことがなく、経験と勘と昔取った杵柄だけで食ってるので、そういう意味では若干の後ろめたい気持ちもある。で、テストって何なん俺が
DevOpsなんてくそくらえ - razokulover publog
先日こんなことを言われた。 「テストを書いた成果を見せよ」 と。 ショッキングだった。 経緯 わたしはいまレガシーなコードに囲まれている。 もちろんテストもほとんどないピカピカのレガシーちゃんである。 レガシーちゃんは「Ctrl+F5 & tail -f 駆動開発」により開発が進められており、日々進化している。 このまま進化をつづけるといつかモンスターになり(もう軽く怪獣っぽいが)、開発スピードがどんどん遅くなり、メンテナンスやバグつぶしでエンハンスとなるような開発ができなくなる。このままじゃマズい...。 こういった事態を一新すべく、手探りながら私含め数人の先輩たちで「DevOps」に取りかかることになった。 バズワードにもなっているが「DevOps」とは、 従来型のシステム管理や調達（ITILを含む）といった、保守的でプロセスを中心に据えた運用からよ>り戦略的でアジャイルな、そして自動
テスト書きすぎ問題 - hitode909の日記
テスト書きすぎるとよくないって言ってる人がいた．DHHっていう人．作業時間の1/3以上テストしてたらおかしいとか，ActiveRecordのバリデーションなど，Railsの機能はテストしない，とか． Signals vs. Noiseの去年のエントリに、テストをどれくらい書くべきかということについてDHHが指針を示していたものがあったので... - Sooey 偉い人が言ってるからという理由で，テスト手抜き派の人に良い材料を与えてしまった．僕は意見ちがって，作業時間半分以上はテスト書いたりしてる． テストたくさん書くと，最初に書くときのコストは増える．けど，あとから読む時や，変更したい時には，読むだけだし，書くのも差分だけで良い．コード本体を理解できれば，要らないテスト捨てるのは，落ちたのを消すだけだから簡単．あとで見て，テスト足りないと分かったときに，明文化されてない仕様からテストを補う
いまだにユニットテストって受け入れられないんだろうな - 個人的なまとめ
色んな所で「テスト(ここではユニットテスト)を書かないのは小学生までだよねー」とか、もっと汚い言葉で言われたりするけど、いまだにうちのチームでは自分だけしか書かない現状が悩ましい。 Jenkinsさんが激おこになっても誰も何も反応しない。 もちろん、全部が書けるとも思ってないので、自分が不安なところとか、変更が多く入りそうなところとかを中心に書くようにしてる。一種の精神安定剤みたいなもん。 あるとき、一緒に働いてるエンジニアさん(ここではAさんとしておこう)に「ここ難しそうだから、テスト書いたほうがいいですよ」って話をしたら、「じゃぁ、工数かかっちゃいますね」って言われて結局書いてなかったな。 そうだよ。ユニットテスト書いたら工数かかるよ。それは純然たる事実。でも、再利用できないチェックシートを作ってやるよりもいいと思うんだけどね。しかもこの前に見せてもらったこのチェックシートも運用レベル
FINDJOB!終了のお知らせ | FINDJOB!
FINDJOB! 終了のお知らせ 2023年9月29日にFINDJOB!を終了いたしました。 これまでFINDJOB!をご利用いただいた企業様、求職者様、様々なご関係者様。 大変長らくFINDJOB!をご愛顧いただき、誠にありがとうございました。 IT/Web系の仕事や求人がまだ広く普及していない頃にFind Job!をリリースしてから 約26年間、多くの方々に支えていただき、運営を続けてまいりました。 転職成功のお声、採用成功のお声など、嬉しい言葉もたくさんいただきました。 またFINDJOB!経由で入社された方が人事担当になり、 FINDJOB!を通じて、新たな人材に出会うことができたなど、 たくさんのご縁をつくることができたのではないかと思っております。 2023年9月29日をもって、FINDJOB!はその歴史の幕を下ろすこととなりましたが、 今後も、IT/Web業界やクリエイティブ
テスト分析・テスト設計入門
© 2013 Fuji Xerox Co., Ltd. All rights reserved. ■JaSST 2013 四国 テスト分析・テスト設計入門 富士ゼロックス株式会社 ソリューション・サービス開発本部 秋山 浩一 2 自己紹介 1985年4月 富士ゼロックス入社 現在はHAYST法のコンサルティング業務に従事 NPO ソフトウェアテスト技術振興協会（ASTER） 理事 JaSST東京実行委員（2003年～） 日本最大のテストシンポジウム1600名の動員 JSTQBステアリング委員（2006～） テスト技術者資格認定を行う国際組織日本支部 日科技連 SQiP研究会 委員長（2011年～） Wモデル研究会 主査（2011年7月～） 電通大 西康晴先生、NEC 吉澤智美氏、MRT 鈴木三紀夫氏 ISO/IEC JTC 1/SC7 WG26委員（20
テストエンジニアリング、DevOps のこれから #testingcasual - naoyaのはてなダイアリー
一昨日 Testing Casual Talks #1 に参加した。名前の通り、ソフトウェアテストに関するカジュアルなカンファレンス。とても面白かった。すこし思ったところを書いていこう。 テストのエンジニアリング トップバッターの @ikasam_a さんの発表では Software Engineer in Test at DeNA ということで、氏が勤務先でテストエンジニアリング部門を立ち上げていくにあたってのいきさつや背景といったところが述べられていた。 テストは開発者の生産性を向上するためにある、生産性向上のためにテストを書くテストエンジニア、近年複雑化するテストの実行環境を構築するのもテストエンジニアの役目、"Testing Activities SHOULD be in Developments" ─ テスト活動は (従来型のQAのように開発の外ではなく) 開発の中で行われるべき
ゆーすけべー日記
ここ最近の僕の開発で指標になっているのは「システムとしてのクオリティを上げるか」であり、それって当然のごとく行われているかもしれなくて、いわゆる Quality Assurance = QA なんて言葉があったり、某社では Test Engineer の方がいたりするわけです。ただ、あまりにも僕としては「ずさんな」ところが多々あると考えています。「よしAを変更した → デプロイ → Bがエラー出てる」なんてことがないように「機能が望むように動作しているか」をテストコードで担保しようと努めている次第です。例えば、先日サービス内で使用している Flickr API の一部メソッドが正常に機能しない（ どんなに一般的な語彙で探しても検索結果が空で返ってくる ）なんてことがありましたが、テストコードのおかげで問題の切り分け、つまり、これは本当に Web API が壊れているのだ！ということがテスト
TDD Anti-patterns catalogue at Stack Overflow を簡単に訳してみた - joker1007’s diary
Stack OverflowのTDD Anti-patterns catalogueというスレがとても面白かったので訳してみた。 Stack Overflowのvoting機能でアンチパターンへの投票を行っている感じ。 上から投票の多い順になっている。 得票数はこの記事執筆時点(2013.7.9)のもの。 SQLアンチパターンっぽく、パターン名はそのまま片仮名にしてみた。 また、内容がかなり被っているとか、状況がかなりレアじゃないかと思うものは、一部省略しました。 (ブコメで訳間違ってるよ、って教えてもらったので、一部修正しました 2013.7.10) フリーライド (テストのただ乗り) 50pt 新しいテストケースを書くのではなく、他の機能のテストに新しいアサーションを追加して既存のテストケースに乗っかる。 セカンドクラス シティズン (二等市民) 47pt プロダクションコードのように
第106回 品質保証の役割を考える（全4回の第2回）｜SQiP：Software Quality Profession
「ソフトウェア品質のホンネ」連載中！ SQiPポータルサイトでは、SQiP委員のソフトウェア品質へのその想いをコラム的に綴る 「ソフトウェア品質のホンネ」のコーナーを好評連載中です。 肩肘張らずに気軽にお読みいただける内容を掲載していきますので、お仕事の合間などに是非ご覧ください！ ※本コーナーに対するご意見、ご感想がありましたら、sqip@juse.or.jpまでお寄せください。 ２．ソフトウェア品質保証の変遷（Fの例） １）品質保証部署の設置 わたしが勤務していた会社（F）の中にソフトウェア製品の検査（検査部という組織名称であったので品質保証とせずそのまま｢検査｣を用います）を担当する部署が設置されたのは1968年と聞いています。この時代は、品質保証というよりもテストノウハウやデータの取得を目指していたと聞いています。ハードウェア装置の検査方法、文献などを頼りにソフトウェア検査の
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
hayst.com
http://www.gaio.co.jp/product/pdf_cat/GAIO_Solutions_2013.pdf
ぼくとJenkinsおじさんの360日戦争
