Github Actionsによる継続的デリバリーの構築 - SO Technologies 開発者ブログ
CTO室所属の高橋と申します。皆からはニャンさんと呼ばれております。そして私は特に無茶振りはされていません。 さて、developブランチに変更が入ったらdev環境にリリース、mainブランチに変更が入ったら本番環境にリリースを行う仕組み、いわゆる継続的デリバリーを構築しているプロジェクトは多いことと思う。我々のチームではCircle CIで行なっていたが事情があってGithub Actionsに移行することになった。ところがGithub Actionsではdevリリースと本番リリースの手順をどう共通化すればいいのか分からず迷ってしまった。 近年のソフトウェア開発の現場ではCI/CDは当たり前になっているが、もはや当たり前すぎて逆にまとまった情報がネット上にないのかもしれない。であれば得られた知見は共有しておくべきだろう。 結論から言うとジョブの共通化には再利用可能なワークフロー用いるのが
ユニットテストってもう言わない！ CI/CD時代のテスト分類に最適なテストサイズという考え方
はじめに 以前からユニットテスト/単体テストという言葉は使いづらい、と感じており今回も旧Twitterで「テストを実行時間ベースで分類する良い言葉ないかなー」と呟いていたところ、「テストサイズのSMLって考え方があるよ」と教えて戴きました。 だいたいは教えてもらったt_wadaさんの記事にすべて書いてあるのですが、自分の整理も含めて動画にしたので、その補完記事となります。 TL;DR 単体テストのバベルの塔は既に崩壊 CI/CDでの継続的テストには時間ベースのテスト分類が重要 UT/IT/E2EではなくSMLによるテストサイズがCI/CDには合う それは単体テストか結合テストなのか？ 自動テスト、手動テストに関わらずテストの分類として単体テストと結合テストという言葉は一般的です。 ITQBではTest Levelsという言葉で定義されていますし、以下のようなV字モデルの対応表はみんな知って
テストプロセスが自走するチーム体制をめざして QA が取り組んでいること - Techtouch Developers Blog
はじめに 前提情報 プロダクトチームの体制 Four Keys の Elite を目指して 品質保証の課題 1. テストの重複 2. 刻々と変化するチーム体制 3. 属人化したテストケース管理 改善策：テストプロセスの変更とテストケース管理ツールの導入 1. テストプロセスの改善〜Test It Yourself〜 2. テストマネジメントツールの導入 おわりに はじめに こんにちは、テックタッチで QA PM (Quality Assurance Project Manager)をしている shutty です。先日はテストエンジニア向けの合宿型ワークショップ WACATE2023 冬に初めて参加してきました。実行委員をはじめとして参加者全員の熱量を全身に浴びてきました。 この記事では最近テックタッチの開発チームで行なっているテストプロセスの改善について紹介します。 前提情報 プロダクトチ
【Unity】Code Coverage Package を Github Actions で動かしてみた - Qiita
はじめに Code Coverrage PackageなるものがUnityの中でパッケージ化されていることを皆さんご存じでしたか？自分は知らなかった... 使い方自体はUnityの公式ブログで説明されているので、自分の記事では主にCIを回したときにCodeCoverageが表示されるように自動化するにはどのようにすればよいのかを記事にしたいと思います。 Code Coverageとは？ Code Coverageは、ソフトウェアテストの重要な指標であり、コードがどの程度網羅的にテストされているかを示します。Code Coverageは、品質向上の指標とすることができます。 主なカバレッジの種類には以下があります： 関数カバレッジ: 定義済み関数の呼び出し回数。 ステートメント カバレッジ: 実行されたステートメントの数。 ブランチ カバレッジ: 実行されたコントロール構造のブランチの数（例
game-ci/unity-test-runner で Docker Image が見つからなくてエラーになる
はじめに game-ci/unity-test-runner を用いて GitHub Actions で Unity のテストを実行した際に私が実際に遭遇したエラーと解決方法について記載しました。 筆者の環境 Unity 2022.3.9f1 遭遇した問題 テストに使用した workflow はおおよそ以下のような内容です。(関係の無い部分は省略しています) name: Test on: pull_request: jobs: test: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - uses: game-ci/unity-test-runner@v2 env: UNITY_LICENSE: ${{ secrets.UNITY_LICENSE }} Unable to find image 'unityci/edit
Now in REALITY Tech #80 self-hosted runnerでUnityの自動テスト環境を構築してみる｜REALITY
Now in REALITY Tech #80 self-hosted runnerでUnityの自動テスト環境を構築してみる REALITYのUnityエンジニアのﾎﾝﾀﾞです。 今週の「Now in REALITY Tech」では、自動テスト環境をGitHubのself-hosted runnerを使って構築したので簡単に紹介したいと思います。 self-hosted runnerとは詳しくはGitHubのドキュメントを読んでもらえればと思いますが、簡単に説明すると以下の通りです。 GitHub Actions からジョブを実行するためにデプロイおよび管理するシステム GitHubが管理しているGitHub ホステッド ランナーよりも細かく制御できる 物理または仮想にでき、コンテナー内、オンプレミス、またはクラウドに配置できる GitHub Actionsを実行する環境を自前で設定でき
CI/CD方針、テスト・QA方針と連動する三分類ブランチ管理方針で、開発での高品質と高スピードの両立を支える - 千里霧中
最近の開発では、CI/CD、自動テスト、継続的テストが当たり前となっていますが、その影響で、それらのCI/CD方針、テスト方針と、Git等のバージョン管理のブランチ方針をどう連携させるかが、定番の課題になっていると感じています。 今回は、このブランチ方針、CI/CD方針、テスト方針を連携させて、開発の品質とスピードを向上させるアプローチについて解説します。 結論から言うと、要点は以下の二つとなります。 バージョン管理のブランチ方針は、CI/CD方針、テスト・QA方針と不可分であり、連携を考えながら方針立てする必要がある ブランチ方針の工夫で、CI/CD、テスト・QAの開発インフラリソース消費を削減でき、本当に重要なポイントに開発インフラリソースを投入できる。これにより、限られたリソースでの高品質・高スピードの両立を支えられる 背景：開発インフラの進化が全てを解決すると楽観視していた発展期
バッチモードでUnityを実行するときの制限事項と回避方法 - やらなイカ？
本記事は、拙著『Unity Test Framework完全攻略ガイド 統合テスト編』の付録Bから抜粋したものです。 バッチモードとは バッチモードとは、Unityエディターをコマンドラインから起動するときに -batchmode オプションを付けることでヘッドレス動作するモードです。 ウィンドウモード*1のUnityエディターは実行中さまざまな、人間が応答しなければならないポップアップウィンドウが表示されますが、バッチモードでは表示されません。そのため、CIでテスト実行するときなどに使用されます。 バッチモードの制限事項 本記事執筆時点で判明している、バッチモード実行時の制限事項は次のとおりです。 スクリーンサイズは640×480 WaitForEndOfFrame を使用できない*2 InputSystem.TestFramework を長時間（数十秒）動作させたとき、途中で操作が止ま
C#でSonarQubeでカバレッジを表示する - Qiita
1. はじめに SonarQube（自動コードレビューツール）にカバレッジを表示したい カバレッジはOpenCoverで解析して、その内容をSonarQubeへ反映したい 2. 開発環境 C# .NET 6 Visual Studio 2022 SonarQube OpenJDK 17 OpenCover ReportGenerator 3. SonarQubeのインストール SonarQube(Community Edition)を下記サイトよりダウンロードしてインストールする 4. JDK17のインストール SonarQubeを起動するためJavaを使用するため、下記サイトよりダウンロードしてインストールする 5. SonarQubeを起動 SonarQubeをインストールしたフォルダ内のStartSonar.batを起動する http://localhost:9000\ へアクセスし
Go/Docker/GitHub Actions環境でのDBテスト方法検討
はじめまして2022/11に入社しましたソフトウェアエンジニアの葛西です。 主にバックエンド開発を担当しています。 社内で競プロ部を立ち上げたのでいつか機会があれば記事にしたいなと思っています！ はじめに チーム内で現在のプロジェクトのDB(リポジトリ層)単体テストをどういう風にやろうかという話になり、色々悩みながらやり方を検討していったのでその過程と最終的にどのように実装したかを残しておきたいと思い記事にしました。 技術スタック まずDBテスト方法を検討する際の前提条件として現在のプロジェクトで使用している技術スタックを書いておきます。 言語 Go DBマイグレーションツール sql-migrate スキーマ変更用のSQLを用意しておけばコマンドでスキーマ変更などを反映してくれるというツールです。 スキーマ変更用のSQLはこのプロジェクトのディレクトリに直接置いています。 ORMライブラ
第3回 テストサイズ ～自動テストとCIにフィットする明確なテスト分類基準～ | gihyo.jp
テストの分類として開発者に馴染み深いのは、検証の対象となるコードの範囲や粒度での分類でしょう。範囲が狭く粒度が細かい順に、ユニットテスト、インテグレーションテスト、E2E（end to end）テストなどと呼ばれます。今回は、自動テスト前提の時代にうまくフィットするテスト分類について考えます。 現場の混乱 実は、範囲や粒度による分類に現場は混乱しがちです。「1つの対象」を検証する狭いテストをユニットテスト、単体テスト、コンポーネントテストなどと呼びますが、これらをほぼ同じものと言う人も、異なると言う人もいます。「1つの対象」も関数、メソッド、クラス、モジュール、パッケージ、振る舞い、1つの画面と、人や組織によってバラバラです。 複数のレイヤ、たとえばコントローラとモデルをまたいで検証するテストをインテグレーションテストと呼ぶ人もいれば、それもユニットテストと呼ぶ人もいます。ユニットテス
ユニットテストをGitHub ActionsからCodeBuildに移行し、実行時間を35%削減した - Uzabase for Engineers
こんにちは。NewsPicks SREチームの 海老澤 です。 今回はGithub Actionsで実行していたテストを高速化したので紹介したいと思います。 課題 取り組み テストの並列化 AWS CodeBuildへの移行 CodeBuildの設定 コンピューティングタイプ トリガー buildspec.yml 結果 課題 NewsPicksでは Junitのテスト等をGithub Actions から実行しているのですが、2013年のサービス開始当初から存在する、一番コードベースが大きいリポジトリのビルド・テストの実行時間に 20~30分ほどかかっていました。 テスト自体はバグを産まないためにも必要なものですが、時間がかかるため開発効率が下がってしまいます。そのためテスト高速化の取り組みを行いました。 取り組み テストの高速化をする上でやったことは大きく下の二つです テストの並列化 G
コードの複雑度をあげる Pull Requests を GitHub Actions で止めよう
循環的複雑度が閾値を超えた Pull Requests に、自動的に変更をリクエストする 「コードの品質を、維持したいよーーー」 ということで、テストや Linter を GitHub Actions で実行している環境はよくあると思いますが、今回は 循環的複雑度 を継続的に計測して、閾値を超えた場合に自動的に Pull Request に対して Request Changes のレビューをしようという試みです。 Lizard この例では、Lizard を使用して CCN を計測します。 おそらく似たようなツールでも同様に実行することができると思います。 Lizard は Python で開発されている CCN 計測ツールです。（追記：シンプルに書いてしまいましたが、もちろん他の指標も計れます） 以下のようにサポート言語が多いので、大抵の場合で採用できそうです。 サポート言語 (1.17.
GitHub ActionsとCypressを使って、テスト自動化環境をゼロから構築する - Qiita
はじめに 本記事は、アジャイル開発手法におけるQAの参考になれば、と作成しました。 開発、QA、また今後、それらに携わっていく方々の即戦的知識になればと思います。 また、本記事で作成したソースコードは下記に公開しています。 https://github.com/EIKINAKAYAMA/cypress-demo そもそもテストって？ システム開発では、システムがリリースされるまで、 作成された開発物に問題がないかを色んなテストでチェックします。 UIテスト ブラックボックステスト 負荷テスト リグレッションテスト 退行テスト 受け入れテスト アドホックテスト etc... 上記は一部を載せていますが、まだまだ沢山あります。 会社や組織によって呼び方が変わったり、テストというよりもテスト手法だったり、同じようで厳密には内容が異なったりと多種多様のテストが存在し、必ずしも全てのテストを実施して
自動化大好きエンジニアたちが語る、効率化・品質向上 Tips【26選】 - RAKUS Developers Blog | ラクス エンジニアブログ
こんにちは、技術広報のyayawowoです。 「自動化（オートメーション／Automation）」 今、この言葉を聞いて胸がときめいた方に必見です！ 当社主催イベントでも人気の高い 「自動化大好きエンジニアLT会」全5開催分の資料をまとめて紹介します！ イベント詳細はこちらをご確認ください！ ・自動化大好きエンジニアLT会 ・自動化大好きエンジニアLT会 - vol.2 ・自動化大好きエンジニアLT会 - vol.3 ・自動化大好きエンジニアLT会 - vol.4 ・自動化大好きエンジニアLT会 - vol.5 目次 目次 手動テストやインフラ構築は自動化しよう APIテスト品質を向上させる Datadog Synthetic Monitoring APIテスト自動化とテストピラミッド TestLinkにテスト結果を自動的に登録 Cypressでサクッと始めるE2Eテスト 自動テスト環境を
テスト自動化 / Test automation
プロトタイピングによる不確実性の低減 / Reducing Uncertainty through Prototyping
新卒１年目が荒れ果てた開発環境に１年間でCIを導入し単体テストを布教した話 - Qiita
この記事は 「Develop fun!」を体現する Works Human Intelligence Advent Calendar 2020 21日目の記事です。 昨日の記事は@sparklingbabyさんのStream API がもっとわかる記事でした。 あらすじ 私は2019年にWorks Human Intelligence（正確には分社前の会社）に新卒入社し、 19年10月からプロダクト開発部門に配属され、SETエンジニアとしてとある製品のJava開発環境の改善に取り組んでいます。 ざっくりとプロダクト開発を紹介するとこんな感じです。 3万クラス程度ある大規模Java Webアプリケーション 開発環境はEclipseを使用 開発者のOSはWindowsのみ Before 私が開発チームに参加した時点では 部門として新規開発に注力しており、足下の環境改善をやる担当者がおらず、 い
精神安定剤としての「E2E自動テスト」と「CI（継続的インテグレーション）」のすすめ - Qiita
アドベントカレンダー私が担当する最後の記事は、アプリの品質を保つ上で最も重要なテストについてです。 以下の記事の続きという前提なので、React+AWSで作成したWebアプリ（SPA）に自動テストのフローを追加するという流れで今回の解説を行います。 AWS Amplify / AppSyncで画像投稿webアプリのサーバサイドを実装する テストと聞くと「あんまやる気でねー」となるかもしれませんが、テストがないとリリース時に常に肝を冷やしながら作業をするはめになるので、そんなリスクを犯すくらいならテストしっかり書いておくことで、精神安定剤のかわりになってくれます。 そんなわけで、弊社では自動テストコードをしっかり書いて、作業時・リリース時に必ず回すというフローに対してかなり重きをおいています。1回テストコードを書いておけば、繰り返し使いまわせますしね。 テストと一言で言っても、単体テスト・結
【改訂版】継続的にiOSアプリのパフォーマンスを計測する - DeNA Testing Blog
はじめに SWETグループiOSチームのkariad(@kariad_uu)です。 本記事はiOSDC 2020 Japanにて発表した「継続的にアプリのパフォーマンスを計測する」の内容を元にブログという形で改めて紹介する記事となります。 発表時のスライドは以下を参照ください。 iOSチームではiOSアプリのパフォーマンス計測に取り組んできました。 iOSアプリのパフォーマンス計測方法はたくさんありますが、中でもInstrumentsを利用したパフォーマンス計測とその自動化について紹介します。 なぜパフォーマンス計測が必要なのか？ 取り組んだ計測方法についてご紹介する前にアプリにとってパフォーマンスとその計測がなぜ重要なのかという点を説明します。 起動に時間がかかる、読み込みに時間がかかるアプリは動作が遅くユーザにストレスを与えてしまいます。 短時間で熱くなってしまうアプリでは端末が熱くて
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - stepci/stepci: Automated API Testing and Quality Assurance
