チームのテスト力を総合的に鍛えてシフトレフトを推進する/Shifting Left with Software Testing Improvements
こんにちは、クラウド&ネットワークサービス部の福岡です。 SDPF（Smart Data Platform） クラウドの IaaS である、ベアメタルサーバー・ハイパーバイザーサービス開発のソフトウェアエンジニアとして働いています。 本記事では、リリースプロセスの改善を目指して QA チームが実施している試験の一部を自動化したことで、チームの底力が爆上がりした事例について紹介します。 SDPF ベアメタルサーバーサービスのミッション 機能リリースまでの流れと課題 課題1: 価値提供までのリードタイムが長くなる 課題2: QA チームの稼働がひっ迫する QA 削減に向けた取り組み 〜自動テストによる代替〜 思いがけない困難 どうやってこの困難に立ち向かったのか 1. 締切のあるタスクと締切のないタスクをセットにして取り組む 2. チームでサービス説明書の読み合わせ会を実施 取り組みの成果 1
# トレーニングジムの予約システムを開発していると仮定してください 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) { user.billings.first } it { expect(user.billings.count).to eq 1 } it {
はじめに みなさん、DRY原則はご存知でしょうか？ DRY = Don't repeat yourselfの略で「繰り返しを避けること」という意味ですよね。 良いコードを書くための重要かつ基本的な原則なので、みなさんよくご存知だと思います。 ですが、DRY原則はテストコードを書く場合は必ずしも最善にはならない場合があります。 他の人が書いたテストコードを見ていると、テストコードにDRY原則を適用したために、かえって悪いコードになっているケースをときどき見かけます。 この記事ではなぜテストコードをDRYにすると良くないのか、ということを説明します。 追記：タイトルを変更しました @t_wada さんのコメントを受けて、タイトルを見直しました。 「テストコードはDRYを捨ててベタ書きする」 => 「テストコードの期待値はDRYを捨ててベタ書きする」 【注意】この記事は画一的なテストコードの書き
For our back-end here at Plato, we decided to give NestJS a try. NestJS is easy to set up, it helps consistency and modularity, and integrate easily with the powerful TypeORM library. As our POC started to grow, we wanted to improve the robustness of our project by adding integration tests. We already had a decent code coverage but unit tests are not quite enough as it forces us to hide the comple
環境 NestJS 7.0.7 nestjs/typeorm 7.0.0 typeorm 0.2.25 factory.ts 0.5.1 やりたいこと/やること DB層にアクセスする処理（SQL）を、実際のデータを使ってテストする。 factory.tsを使ってオブジェクトを生成し、事前にDBにsaveすることにより、テストデータを用意する。 各テストが独立して動作するように、テスト毎にテーブルを空にする。 factory.tsを選んだ理由 typeorm-fixturesも存在し、2020/4時点でこちらの方がStar数も多く（factory.tsの120に対して221）、最終更新日も最近だったが（2019/12に対して2020/4）、以下の理由でfactory.tsを使うことにした。 factory と fixture の比較で、factory が好みだった（テスト毎に独立したデータを
こんにちは。コネヒト歴7ヶ月目のWebエンジニアの古市です。 私の所属するチームではReactで構築されたCMSを開発しています。 Atomic Designに則り、コンポーネントを Atoms/Molecules/Organisms/Pagesの区分で作成しています。このうち、Atoms,Molecules,OrganismsについてはJest+react-testing-libraryの組み合わせで必ずテストを書くようにしています。 今回は実際に書いているテストコードを例に挙げながら、どのような点をテストコードで担保しているか、また、テストを積み重ねるための施策について説明いたします。 具体的なテストコード これは業務で書いているテストコードを抽象化した一例です。 以下のような構造のコンポーネントのテストだとイメージしていただければと思います。 名前が表示される アバター画像が表示され
はじめに みなさんこんにちは！ この記事は「必要最小限の努力で最大限実戦で使える知識を提供するRSpec入門記事」、略して「使えるRSpec入門」の第3回です。 今回はRSpecのモックを使ったテストについて説明します。 これまでモックを全く使ったことがない人でもわかるように丁寧に説明していくつもりです。 また、これまでの回と同様、個人的に使用頻度が低いと思っている内容についてはバッサリ説明を省きます。 ただし、第1回や第2回に比べるとテストコードが少し複雑になって、仕組みや動きを想像するのがちょっと難しいかもしれません。 ぱっと頭に入ってこない場合はじっくり本文を読んだり、実際に自分で写経しながらコードを動かしたりするなどして、少し時間をかけながら理解するようにしてください。 今回は以下のような内容を説明します。 モックの基本的な使い方 モックを使った検証 モックでわざとエラーを発生させ
New Project 🐷 Porkybank: Track your daily budgetLearn to Code Like a DeveloperCodeamigo is an AI powered coding assistant that helps you learn to code like a developer. Today's developers didn't learn binary before learning Python, why should you learn how to code without the most modern tools?PSA: I will no longer be maintaining Codeamigo. I am working on a new project called Porkybank. It's a t
要約 / inb4 tl;dr 成瀬允宣さん（Twitter , nrslib ）の 『ドメイン駆動設計入門 ボトムアップでわかる！ドメイン駆動設計の基本』 を読んでサンプルコードを Laravel で実装してみた。 DDD 入門として、とても良い書籍だったのでオススメ。 実装の前提条件やポイントをまとめた。 ※注：この記事は、あくまでサンプルコードの書き起こしと整理のみです。DDD 本来の設計作業についての記載はほとんどありません。 コードはこちら anfangd/laravel-ddd-sample-for-beginners - GitHub はじめに 2020年2月9-11日に開催された PHPerKaigi2020 に参加してきました。 PHPerKaigi 2020 こういうイベントごとには滅多に参加してこなかったのですが、今回は少し足を伸ばして練馬まで行ってきました。 沢山学
はじめに CX事業本部の佐藤智樹です。 今回は先月中頃に実施したLambdaのテスト領域に関する技術共有会の資料と当日にいただいた意見を紹介します。技術共有会自体はお客様含め5人ほどで実施予定でしたが、社内の方を誘ったところ15人程と大人数でディスカッションしながら知識を深めました。有意義な時間となったのでブログで共有します。 本記事はLambdaに対してどのようなテストをすべきか、Lambdaでこれからテストを書くがどうやれば良いか悩んでいる方などは参考になるかと思います。いくつか紹介するテストパターンのメリット/デメリットもあげるので、テスト選定の上で参考にしてください。 例となる題材がなければ抽象的な話ばかりになり分かりづらくなるので、今回は以下のIoTデータ収集システムをベースにどうテストを書いていくか検討します。IoTデバイスからきたデータをRDSに保存するシステムです。色々書い
こんにちは、Autify CEOの近澤（@chikathreesix）です。 先日会社の紹介資料を公開しました。大変嬉しいことに多くの反響を頂いているのですが、会社の紹介資料には自動化に賭ける僕の熱い想いは詰め込めきれませんでした。そこで、なぜ我々が今テスト自動化に取り組んでいるのか、なぜテスト自動化がこれからの社会において重要なのか、改めてブログにまとめました。 テストの大半が未だに人手ソフトウェアテストとは、開発したソフトウェアが正しく動作するか検証する作業のことです。ですのでソフトウェアを開発するあらゆる組織において、テストを実施する必要があります。市場は非常に大きく、IT予算の1/3をテストに使っていると言われ、その額は130兆円にも登ります。 この作業ですが、未だにグローバルで見てもおよそ75%の企業が人手に大きく依存しています。人手のテストは当然人件費と時間が多くかかるわけです
2020年になって、CircleCIのCI用の公式ベースイメージはcimg/base派生になった。 ただ、2020/06/07現在、Go向けの言語別公式ガイドの中身は古いままである。 cimg/goを使ったGo向けのCircleCIの設定をまとめる。 TL;DR CircleCIで利用するコンテナイメージに次世代版が登場した。 https://hub.docker.com/r/cimg/go 直接使わなくても、Orbsが便利 https://circleci.com/orbs/registry/orb/circleci/go go/mod-download-cachedでキャッシュとGo Modules周りがすぐ解決。 go-junit-reportをgo getしなくてもよい gotestsumコマンドがデフォルトインストールされている GOPATHは変更されているので注意する /hom
![[Go]次世代イメージcimg/goとcircleci/go Orbsを使った2020年版CircleCIの環境構築 - My External Storage](https://cdn-ak-scissors.b.st-hatena.com/image/square/f3ca5145f819bb37539bafba90f1c2353dbe1f00/height=288;version=1;width=512/https%3A%2F%2F2.zoppoz.workers.dev%3A443%2Fhttps%2Fbudougumi0617.github.io%2Flogos%2FGo-Logo_Aqua.png){kind=logo}
この文章の背景について この文章はテスト容易性設計をテーマに 2013/11/26 に CodeIQ MAGAZINE に寄稿したものです。残念ながら CodeIQ のサービス終了と共にアクセスできなくなっていたため、旧 CodeIQ MAGAZINE 編集部の皆様に承諾いただき、当時の原稿を部分的に再編集しつつ、ライセンス CC BY（クリエイティブ・コモンズ — 表示 4.0 国際 — CC BY 4.0） で再公開いたしました。 旧 URL にいただいたブックマークとご意見はこちらです（これであなたもテスト駆動開発マスター！？和田卓人さんがテスト駆動開発問題を解答コード使いながら解説します～現在時刻が関わるテストから、テスト容易性設計を学ぶ #tdd｜CodeIQ MAGAZINE）。旧記事には本当に多くの反響をいただき、誠に感謝しております。 目次 この文章の背景について 目次 出
Netlify’s command line interface (CLI) lets you configure continuous deployment straight from the command line. You can use Netlify CLI to run a local development server that you can share with others, run a local build and plugins, and deploy your site. The sections below describe how to perform common tasks with Netlify CLI. You can also access a full command reference online, or get help within
Introduction Environment Creating Tests Running Tests Running Tests in Parallel Reporting Test Coverage Profiling Tests Introduction Laravel is built with testing in mind. In fact, support for testing with Pest and PHPUnit is included out of the box and a phpunit.xml file is already set up for your application. The framework also ships with convenient helper methods that allow you to expressively
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
