高品質と高スピードを両立させるテストアプローチ/Test Approach that Improves Quality and Agility Together
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人を超える品質とエンジニアリ
単体テストの単位はコードではなく振る舞いである 2023.01.07 単体テストの目的は、ソフトウェア開発プロジェクトを持続可能なものにすることです。この目的を達成するための単体テストの機能の 1 つにリファクタリングに対する耐性が上げられます。これは内部のコードを変更した前後でも、外部の振る舞いから見た振る舞いが壊れていないことを保証してくれる度合いです。この耐性が高ければ、開発者は安全にコードを変更できます。 この記事では、単体テストをコード単位で書いた場合と振る舞い単位で書いた場合をそれぞれ提示して、リファクタリングに対する耐性がどのように異なるのかを見ていきます。 単体テストの目的は、ソフトウェア開発プロジェクトを持続可能なものにすることです。この目的を達成するための単体テストの機能の 1 つにリファクタリングに対する耐性が上げられます。これは内部のコードを変更した前後でも、外部の
テストコード内では条件分岐を書かないようにする 2023.01.21 誰でも読める愚直なコードであることの 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
with AIRefraction is a code generation tool for developers. It uses AI to generate code for you. You can use it to generate unit tests, documentation, refactor code and more. Generate code in Generate code using AI in 56 languages — ABAP, Ada, Apex, Assembly, Batch, C, C#, C++, CameLIGO, Clojure, Cobol, CoffeeScript, CSS, D Lang, Dart, Elixir, Erlang, F#, Fortran, Go, GraphQL, Groovy, Handlebars,
Humble Objectパターンとは Humble Objectパターンはソフトウェアのデザインパターンの1つ。 Humble Objectパターンを用いることで、ユニットテストが書きやすくなる。 Humbleは 「控えめ」 という意味で、テストしにくいロジックとテストしやすいロジックを分離し、 テストにくいロジックが控えめになるよう分割すべき というものになる。 Humble Objectパターンの対象となるもの Humble Objectパターンの適用が必要なものを考えてみる。 GUI 。一般的にGUIに関する処理はテストがしにくい。iOSアプリ開発で言えば、UIKitに依存した処理はテストがしにくい。この場合は、UIKitに依存する処理をView に該当するクラスに寄せ、UIKitに依存しない処理を Presenter や ViewModel に寄せる。例えば特定条件の場合に文字を
当たり前すぎるかもしれないけど、ちゃんと言語化しておきたいと思いブログにした。 test('Service posts message via API', () { // Arrange final apiClient = MockApiClient(); final databaseClient = MockDatabaseClient(); final service = Service( apiClient: apiClient, databaseClient: databaseClient, ); // Act service.postMessages(); // Assert verify(apiClient.postMessage()); }); test('Service returns the list of messages', () { // Arrange final
追記: 2024-07-20 Testcontainers を使いましょう。 概要 dockertest は go でテストを書く際に docker 経由で指定したコンテナを起動してくれてテストが終わったらコンテナを削除してくれる便利ライブラリです。 モチベーション 時雨堂では TimescaleDB という PostgreSQL に TSDB 拡張を追加した少し変わった RDBMS を利用しています。 TimescaleDB 専用の関数があったりするため、モックなどを使わずにテストを書くのが現実的です。 dockertest ory/dockertest: Write better integration tests! Dockertest helps you boot up ephermal docker images for your Go tests with minimal wo
はじめに 本記事は、ソフトウェアテストの小ネタ Advent Calendar 2022の19日目の記事です*1。 本記事では、テストケース*2で具体的な代表値を使うときに気をつけている「2以外の一意の素数を使う」という方針について書きます。なお、この方針は私の個人的経験及び主観に基づいたものです。「必ずしもこのやり方が正しい」と主張したい訳ではないことをご了承ください。 記事では、この方針をさらに「2を使わない」「一意の数を使う」「素数を使う」の3つに分割して説明します。 目次 はじめに 目次 テストケースの具体的な代表値に2を使うのを避ける テストケースの具体的な代表値は一意の数を用いる テストケースの具体的な代表値に素数を用いる 注意:今回の考えはあくまでも代表値の場合の話です おわりに 補足:厳密な素数を選ぶわけではない 1. 「691」という数字が素数であるか判断が難しいため 2
はじめに Unit Testが大事、ということ自体はあまり異論はないと思うのですが、最初からTDDがしっかりできてるような現場ならいざ知らず、そうではない場合は中々うまく入れれない事も多くあります。なのでこうすると導入しやすい、という観点で以下の動画でそのあたりのことを話したのですが、補足も含めて記事でもまとめておきたいと思います。 これはユニットテストですか? ユニットテストとは? ユニットテストとは何でしょうか? 一応、テストの資格試験を実施しているISTQBの定義では以下のように定義されます。 component testing (unit testing) A test level that focuses on individual hardware or software components. Synonyms: module testing, unit testing この
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く