リリースプロセス改善のために工夫して自動化を推し進めたらチームの底力が爆上がりした話 - NTT Communications Engineers' Blog
こんにちは、クラウド&ネットワークサービス部の福岡です。 SDPF（Smart Data Platform） クラウドの IaaS である、ベアメタルサーバー・ハイパーバイザーサービス開発のソフトウェアエンジニアとして働いています。 本記事では、リリースプロセスの改善を目指して QA チームが実施している試験の一部を自動化したことで、チームの底力が爆上がりした事例について紹介します。 SDPF ベアメタルサーバーサービスのミッション 機能リリースまでの流れと課題 課題1: 価値提供までのリードタイムが長くなる 課題2: QA チームの稼働がひっ迫する QA 削減に向けた取り組み 〜自動テストによる代替〜 思いがけない困難 どうやってこの困難に立ち向かったのか 1. 締切のあるタスクと締切のないタスクをセットにして取り組む 2. チームでサービス説明書の読み合わせ会を実施 取り組みの成果 1
【アンチパターン】Arrange、Act、Assert（AAA）を意識できていないRSpecのコード例とその対処法 - Qiita
【アンチパターン】Arrange、Act、Assert（AAA）を意識できていないRSpecのコード例とその対処法RubyRailsRSpec # トレーニングジムの予約システムを開発していると仮定してください describe 'キャンセル処理' do let(:user) { create :user } let(:reservation) { create :reservation, user: user, start_at: '2017-08-10 10:00'.in_time_zone } context '24時間前をすぎるとキャンセル料が発生する' do before do travel_to '2017-08-09 10:00'.in_time_zone reservation.cancel! end after { travel_back } let(:billing)
開発効率を追い求めた実装プラクティス集
この記事は MICIN Advent Calendar 2023 の24日目の記事です。 前回はSaneさんの「データ基盤チームで社内インターンをやってみて」でした。 はじめに abekohです。MICINでMiROHAの開発をしております。 本記事では、書籍等から得た設計・実装パターンの知識や、実際にプロダクト開発で試して得られた経験などから編み出した、開発効率向上のためのWeb API開発のプラクティスを紹介します。 筆者が関わっているMiROHAは治験の業務支援を取り扱うプロダクトです。MiROHAの開発における特性として、以下のようなものが挙げられます。 治験業務に関するドメインが特有で複雑 前例が少なく、MVPを追求中。プロダクトのアプローチが頻繁に変わる 外部品質は高い水準が求められる これらの特性を意識して開発を促進させるために日々試行錯誤しております。 複雑なドメインに対す
テストコードの期待値はDRYを捨ててベタ書きする ～テストコードの重要な役割とは？～ - Qiita
はじめに みなさん、DRY原則はご存知でしょうか？ DRY = Don't repeat yourselfの略で「繰り返しを避けること」という意味ですよね。 良いコードを書くための重要かつ基本的な原則なので、みなさんよくご存知だと思います。 ですが、DRY原則はテストコードを書く場合は必ずしも最善にはならない場合があります。 他の人が書いたテストコードを見ていると、テストコードにDRY原則を適用したために、かえって悪いコードになっているケースをときどき見かけます。 この記事ではなぜテストコードをDRYにすると良くないのか、ということを説明します。 追記：タイトルを変更しました @t_wada さんのコメントを受けて、タイトルを見直しました。 「テストコードはDRYを捨ててベタ書きする」 => 「テストコードの期待値はDRYを捨ててベタ書きする」 【注意】この記事は画一的なテストコードの書き
自動テストの種類の曖昧さが少ない「テストサイズ」という分類 スコープとの掛け合わせでわかる“コスパの良いテスト”
Qiita Conferenceは、ソフトウェア開発者が集まり、最新の技術や最先端の挑戦・ソフトウェアの未来についての考えや知見を共有し、つながる場を創出する、「Qiita」が開催するオンライン技術カンファレンスです。ここで和田卓人氏が「サバンナ便り - 自動テストに関する連載で得られた知見のまとめ（2023年5月版） 」をテーマに登壇。続いて、自動テストのテストサイズについて話します。 自動テスト内の分類基準は明解ではない 和田卓人氏：次に、テストサイズという考え方にいきます。自動テストにも「〇〇テスト」というやつがいろいろあるんですよね。 特に我々ソフトウェアエンジニアにとって馴染み深い名前はユニットテストとか、単体テストとか、インテグレーションテストとか、システムテストとか、エンドツーエンドテストとか。「〇〇テスト」というやつがいろいろあります。それらの分類基準は、実は言うほど明解で
【考察】テストコードのきれいな書き方 - Qiita
作ったものが想定した動作をしているか。 それを確認するために、テスト（試験）を行います。 検証したいことがちゃんと実現できて確認が取れているのであれば、その品質自体は割と気にされないことが多い印象です。 保守・運用・追加開発 をしていくプロジェクトが多くあると思います。 その作業の中で、改善を取り入れていくこともあると思いますが、その中でも一番後回しにされるのが、テストコードの改善のように思います。 推測ですが、「コストによるメリット・リターンが少なすぎる」ことが理由かな…と（開発者目線ではリターンが大きいのですが、運用者目線ですとリターンが少なく見えてしまう）。 であれば、最初からある程度綺麗なものがどういうものかを考え、作成しておけば良いのではないか・・！ ということで、考察していきたいと思います。 前提 考察をするにあたり、言語化した時の表現や意味のズレが発生しやすい部分もあると思い
ユニットテストのガイドラインを作成しました | メルカリエンジニアリング
この記事は Merpay Tech Openness Month 2022 の15日目の記事です。 はじめに こんにちは。Credit Design Teamでバックエンドエンジニアをしている@tanaka0325です。主にメルペイスマート払いの開発をしています。 この記事では、先日私のチームで作成したユニットテストのガイドラインについて紹介します。 課題 現在私が担当している「メルペイスマート払い」のマイクロサービスは、もともと「メルカリ月イチ払い」として提供されていたコードを流用し、新規要件となる機能を追加して作られたマイクロサービスです。 マイクロサービス化するにあたり、「メルカリ月イチ払い」にあったデータはマイクロサービスリリース後に随時マイグレーションをする方針になったので、既存のデータをマイグレーションしつつ、定額払いなどの新規機能を追加してきました。メルペイスマート払いのマイ
使えるRSpec入門・その3「ゼロからわかるモック（mock）を使ったテストの書き方」 - Qiita
はじめに みなさんこんにちは！ この記事は「必要最小限の努力で最大限実戦で使える知識を提供するRSpec入門記事」、略して「使えるRSpec入門」の第3回です。 今回はRSpecのモックを使ったテストについて説明します。 これまでモックを全く使ったことがない人でもわかるように丁寧に説明していくつもりです。 また、これまでの回と同様、個人的に使用頻度が低いと思っている内容についてはバッサリ説明を省きます。 ただし、第1回や第2回に比べるとテストコードが少し複雑になって、仕組みや動きを想像するのがちょっと難しいかもしれません。 ぱっと頭に入ってこない場合はじっくり本文を読んだり、実際に自分で写経しながらコードを動かしたりするなどして、少し時間をかけながら理解するようにしてください。 今回は以下のような内容を説明します。 モックの基本的な使い方 モックを使った検証 モックでわざとエラーを発生させ
Lambdaのテスト領域に関する技術共有会を開催しました | DevelopersIO
はじめに CX事業本部の佐藤智樹です。 今回は先月中頃に実施したLambdaのテスト領域に関する技術共有会の資料と当日にいただいた意見を紹介します。技術共有会自体はお客様含め5人ほどで実施予定でしたが、社内の方を誘ったところ15人程と大人数でディスカッションしながら知識を深めました。有意義な時間となったのでブログで共有します。 本記事はLambdaに対してどのようなテストをすべきか、Lambdaでこれからテストを書くがどうやれば良いか悩んでいる方などは参考になるかと思います。いくつか紹介するテストパターンのメリット/デメリットもあげるので、テスト選定の上で参考にしてください。 例となる題材がなければ抽象的な話ばかりになり分かりづらくなるので、今回は以下のIoTデータ収集システムをベースにどうテストを書いていくか検討します。IoTデバイスからきたデータをRDSに保存するシステムです。色々書い
なぜ今ソフトウェアテスト自動化に賭けるのか | chikathreesix
こんにちは、Autify CEOの近澤（@chikathreesix）です。 先日会社の紹介資料を公開しました。大変嬉しいことに多くの反響を頂いているのですが、会社の紹介資料には自動化に賭ける僕の熱い想いは詰め込めきれませんでした。そこで、なぜ我々が今テスト自動化に取り組んでいるのか、なぜテスト自動化がこれからの社会において重要なのか、改めてブログにまとめました。 テストの大半が未だに人手ソフトウェアテストとは、開発したソフトウェアが正しく動作するか検証する作業のことです。ですのでソフトウェアを開発するあらゆる組織において、テストを実施する必要があります。市場は非常に大きく、IT予算の1/3をテストに使っていると言われ、その額は130兆円にも登ります。 この作業ですが、未だにグローバルで見てもおよそ75%の企業が人手に大きく依存しています。人手のテストは当然人件費と時間が多くかかるわけです
CI 用 Docker イメージ作成におけるベストプラクティス
H2O の CI では長らく、秘伝のタレ的な .travis.yml を使い続けてきたのですが、なにぶん依存関係が多いもので、だいぶメンテナンスが辛い感じになってきていました。また、CI テストで発生したエラーの調査の度に、時間のかかる CI を回さなければならないことが、開発者のストレスとなっていました。 そこで一念発起して、Docker イメージを使った CI に切り替えることにしました（実行環境としては引き続き Travis を使います）。 その際に、要件として以下のようなことを考えました。 CI以外に、コミット前のテストにも使えるようなイメージにすること コマンド一発でビルドとテストが動作すること 無駄な処理をしないこと その結果、以下のような実装になりました。 テストに必要なソフトウェア群をインストールしたイメージを Docker Hub にアップロードしておく テストには、1.
テスト自動化研究会 - テスト自動化の8原則
1. 手動テストはなくならない 2. 手動でおこなって効果のないテストを自動化しても無駄である 3. 自動テストは書いたことしかテストしない 4. テスト自動化の効用はコスト削減だけではない 5. 自動テストシステムの開発は継続的におこなうものである 6. 自動化検討はプロジェクト初期から 7. 自動テストで新種のバグが見つかることは稀である 8. テスト結果分析という新たなタスクが生まれる これらの原則は、どのようなドメイン、プロセス、ツールの現場におけるテスト自動化であっても共通して言える、テスト自動化に取り組む前に留意しておくべきことがら＝原則を、テスト自動化研究会のメンバーによる議論のうえ、絞り込んだものです。これからテスト自動化に取り組まれる方、現在取り組まれている方、これから見直しをされたい方にご参考いただければ幸いです。 解説 1. 手動テストはなくならない ユーザビリティテ
Go言語でテストしやすいコマンドラインツールをつくる
本記事はGo Advent Calendar 2014の18日目の記事です． Go言語は，クロスコンパイルや配布のしやすさからコマンドラインツールの作成に採用されることが多い．自分もGo言語でいくつかのコマンドラインツールを作成してきた．例えば，GitHub Releaseへのツールのアップロードを簡単に行うghrというコマンドラインツールを開発をしている． コマンドラインツールをつくるときもテストは重要である．Go言語では標準テストパッケージだけで十分なテストを書くことができる．しかし，コマンドラインツールは標準出力や標準入力といったI/O処理が多く発生する．そのテスト，例えばある引数を受けたらこの出力を返し，この終了ステータスで終了するといったテストは，ちゃんとした手法が確立されているわけではなく，迷うことが多い（少なくとも自分は結構悩んだ）． 本記事では，いくつかのOSSツール（得に
Testing in Swift
About the content This content has been published here with the express permission of the author. Software tests are great for verifying software behavior and improving the quality of your code. In this talk, we learn from Jeff Hui about tooling, techniques, and writing tested code with the Quick testing framework. He also talked about generative testing, a prevalent functional programming approac
「ほとんどのユニットテストが役に立たない理由」を読んで | POSTD
数ヶ月前、私はJames O Coplienの ほとんどのユニットテストが役に立たない理由 という記事に出会いました。Jamesはほとんどのユニットテストは無意味であると考えていて、タイトルは内容をそのまま正確に表しています。彼は 追加記事 で議論をさらに展開しています。私は彼の議論に大変興味をそそられました。というのは、私はユニットテストから多くの利益を得ているからです。私たちはどうしてこのような異なる見解を持つに至ったのでしょうか？ 私が何かを見逃したのでしょうか？ 結局のところ私は彼の見解に賛成できませんでした。以下は彼の記事に対する私の意見です。 ユニットテストが必要な場合 私の経験では、ユニットテストはアルゴリズムロジックに対して行う時に最も有益です。結合度の高いコードについてはその性質から特に有益ではありません。結合度が高いコードはユニットテストのために多くのモックオブジェクト
TDD is dead. Long live testing. (DHH)
By David Heinemeier Hansson on April 23, 2014 Test-first fundamentalism is like abstinence-only sex ed: An unrealistic, ineffective morality campaign for self-loathing and shaming. It didn't start out like that. When I first discovered TDD, it was like a courteous invitation to a better world of writing software. A mind hack to get you going with the practice of testing where no testing had happen
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://alanpryorjr.com/2019-05-20-flask-api-example/
bitbucketの使い方