品質やテストといった活動が「本質的にアジャイルになって変わらなければならない」といった問題を定義し、その解決手段を提案する「今、全エンジニアに求められる『アジャイル開発での品質視点の変化』」。ここで株式会社デジタルハーツホールディングスの高橋氏が登壇。最後に、あらためて参加者からの質問に回答します。前回はこちらから。 どうすればうまくリファクタリングができるか 高橋寿一氏(以下、高橋):じゃあここでもう1回Q&Aタイムを取ります。 高木陽平氏(以下、高木):ありがとうございます。今Q&Aにまだ質問が上がっていないみたいなので、ちょっと私から質問します。リファクタリングをしなければいけないところって、逆に手をつけられないようなけっこう複雑怪奇な部分だと思うんです。そこらへんはどうすればうまくリファクタリングができるんでしょうっていう(笑)。 高橋:まず、日本人がすごくリファクタリングが嫌いな
はじめに 〜記事執筆のきっかけ〜 先日、以下の記事についてのツイートが流れてきました。 zenn.dev この記事の内容については、ChatGPTをはじめとするAIによるテストの可能性を示した素晴らしい内容だと思います。 ですが、果たして"今時点(元記事の執筆時点)の"出力結果*1が実用に耐えうるものになっているのか検討し、提示する必要もあると感じました*2。 そこで本記事では、テストエンジニアである私の回答例と"今時点の"AIの出力結果を比較しギャップを示すことを目的とします*3。 決して、AIによるテスト自動生成の進化自体を否定している訳ではないことを念頭にお読みいただければと思います。 結論 本記事では、"今時点の"AIの出力結果に対して、以下の結論を導き出しています。 状態遷移図のテスト設計の題材では、根幹となる機能に関する不具合が含まれていた デシジョンテーブルのテスト設計の題材
(この話は最初Twitterに書こうと思ったけど、長くなるのでブログに書くことにしました) 僕はRSpecやMinitestでテストを書くのは得意ですが、常にテストファースト(TDD)で開発するとは限りません。 今業務でやってるタスクはこんなふうに進めてます。 雑に動くものを作る ↓ 見た目をきれいにする&機能を作り込む ↓ テストを書く ↓ リファクタリングする この順番で開発する理由を以下に述べます。 雑に動くものを最初に作る理由 最初は見た目とか、異常系とか、細かい仕様とかを無視して、正常系が一通り動くものを作ります。 これはこれから作ろうとしているものの認識が合っているかどうかをPO(プロダクトオーナー)に確認するためです。 実際に動く画面を見せると「こんな感じでOK」とか「ここはこういうふうにしたい」というフィードバックをもらうことができます。 また、開発者としてもコードを書きな
はじめにTIG EXU真野です。 積読を消化しようというテーマの、読書感想文連載 の1冊目は、単体テストの考え方/使い方 です。 書籍の基礎情報です 2022年12月28日発売 Unit Testing Principles, Practices, and Patterns の翻訳書。原著は2020年1月14日に発売 テーマ 質の高いテストを行い、ソフトウェアに価値をもたらそう! 単体(unit)テストの原則・実践とそのパターン プロジェクトの持続可能な成長を実現するための戦略 単体テストの原則・実践とそのパターン コード例は C# であるものの、どの言語でも適用できる汎用的な内容とのこと 中を見ると、微妙にC#特有ぽいところに1箇所悩みましたが、それ以外はその通り 翻訳者の須田さんは、他にもセキュア・バイ・デザイン: 安全なソフトウェア設計 やOAuth徹底入門 セキュアな認可システムを
LINE株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。 LINEヤフー Tech Blog はじめに こんにちは。福岡工業大学3年の嵩原ひびきです!QAエンジニアインターン生としてLINE Fukuoka株式会社に2ヶ月間お世話になり、ノンコーディングツールを活用したテスト自動化について勉強させていただきました。この記事では、期間中に学んだ内容について紹介していきたいと思います。 QA Engineering室(以下QAE室)について 私は今回、QAE室という組織にお世話になりました。QAE室ではインターン受け入れの前例がなく、今回が初めてとのことでした。(受け入れありがとうございます!) QAE室は2020年にLINE Fukuoka内に設立された組織で、テストのみならず、要件定義・設計/開発なども含めた開発プロセ
はじめに mablは先日、ソフトウェア開発における品質の専門家たちを讃えるカンファレンス、第3回 mabl Experienceを開催しました。多数のプレゼンテーション、パネルやディスカッションで構成されたこの2日間のイベントは、1200人を超えるソフトウェアテスター、品質リーダー、エンジニアリングの専門家たちにご参加いただき、大盛況のうちに幕を閉じました。Stack Overflow、Chewy、JetBlue、Barracuda、Dawn Foods、Kintent、SmugMugなどの大手企業による多様なセッションを通じて、品質エンジニアリングがソフトウェア業界の基本的変革を大きく支えていることが明らかとなりました。 で紹介されたさまざまな成功例は、当社の第4回「DevOpsにおけるテストの実態調査年次報告書」で示されている傾向と強い相関があります。500人を超える品質とエンジニアリ
単体テストの単位はコードではなく振る舞いである 単体テストの目的は、ソフトウェア開発プロジェクトを持続可能なものにすることです。この目的を達成するための単体テストの機能の 1 つにリファクタリングに対する耐性が上げられます。これは内部のコードを変更した前後でも、外部の振る舞いから見た振る舞いが壊れていないことを保証してくれる度合いです。この耐性が高ければ、開発者は安全にコードを変更できます。 この記事では、単体テストをコード単位で書いた場合と振る舞い単位で書いた場合をそれぞれ提示して、リファクタリングに対する耐性がどのように異なるのかを見ていきます。 単体テストの目的は、ソフトウェア開発プロジェクトを持続可能なものにすることです。この目的を達成するための単体テストの機能の 1 つにリファクタリングに対する耐性が上げられます。これは内部のコードを変更した前後でも、外部の振る舞いから見た振る舞
テストコード内では条件分岐を書かないようにする 誰でも読める愚直なコードであることの 1 つの目安として、テストコードの中に if 文や三項演算子などの条件分岐が入り込んでいていないことが上げられます。if 文が存在するコードはアンチパターンであるといえます。実際に if 文がテストコードの中に入り込んだ例を見てみましょう。 テストコードは誰でも読める愚直なコードであることが求められます。テストコードにはある種のドキュメントのような、コードの仕様を説明する役割が求められているためです。テストの期待結果が変数になっていて、定義元までジャンプしないと値を確認できないだとか、条件分岐やループが入り込んでいて複雑性が上がっている状態ですと、素直に読みやすいとは言えません。 コードの中では重複排除をするためにさまざまなテクニックを駆使することがありますが、これは単にテストコードに適応するべきではあり
AIでユニットテストを自動生成。リファクタリング、ドキュメントの生成、バグの検出なども行う「Refraction」登場 ChatGPTに代表される自然言語やプログラミング言語のコードを理解するAIを用いてコーディングの支援を行うツールがまた新たに登場しました。 Refractionは、示されたコードから自動的にユニットテストを生成するほか、コードのリファクタリング、ドキュメントの生成、バグの検出などを行います。 Updates! https://t.co/9otFTI7nh0 is now https://t.co/MtN5JgnetI. Building out many utilities. You can... Generate unit tests Generate inline documentation Refactor your code Added a $5 / month
2022年9月9日にこんなツイートをしたところ、 ソフトウェアテストの書籍・資料について、こういうマップを作ってみたい。「QA関連」でできるといいんだけど、縦軸が定まらない。 一番繰り返し読んでいるドリル本をサンプルにしてみたけど、テスト分析自体がすでに初級じゃない気もするから、色付けも難しい。うーん。 誰か一緒にやりません?w pic.twitter.com/R0lVJhcpkD— Kazu SUZUKI (@kz_suzuki) 2022年9月9日 「一緒にやってもいいよ~」っていう方々に声をかけていただき、1週間あまりでみるみるできあがっていきました! みなさんの機動力高すぎて、わたしの寄与は「声をかけて最初のフォーマットを作った」くらいになってしまいましたよ。 ということで、以下に公開します! docs.google.com 「閲覧者(コメント可)」というアクセス権を設定しています
ユニットテストとは,おそらくご存知の通り各コンポーネントが単独で操作的に意図通りの振舞いをしているかを具体例により確認する営みである. 「ユニットテストはどのように書かれるべきか」といった議論が為されるとき,もちろん言語横断的な議論が中心となるものの,しばしば特定の計算機言語やその処理系の性質を所与とした議論が含まれやすい.だが,言語仕様や処理系が天から降ってきたものではない以上,原理的にはむしろ言語こそが目的に応じて適切に設計されるべきものだ. したがってここでは,必ずしも明瞭な結論に到達するわけではないものの,「ユニットテストとは普遍的に何をするための仕組みなのか,そしてユニットテストをやりやすく意義のあるものにするためには計算機言語はどんな設計であるべきなのか」ということに関して考え,大枠のアイディアを練ってみたい.ここで触れている内容の一部はおそらくソフトウェア工学の文脈でとっくに
リアルなテストデータを簡単に作ってモック化までできるサービス「Mockaroo」を紹介する❗️データベースのテストデータを作ったり,フロントエンドを実装するときに必要になるバックエンド API をモック化できる.テストデータに test や hoge という文字列を使ってしまうと本番環境相当の確認がしにくく,できる限りリアルなテストデータを作りたい場面は多くあると思う💡 www.mockaroo.com Mockaroo の特徴としては,サポートしてるタイプがなんと現時点で「13 カテゴリ(169 種類)」もある.以下にカテゴリごとにタイプ数をまとめる.What's new を見ると,定期的にタイプは増えている. Advanced(10 種類) Basic(29 種類) Car(1 種類) Commerce(13 種類) Construction(6 種類) Crypto(7 種類) H
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く