チームのテスト力を総合的に鍛えてシフトレフトを推進する/Shifting Left with Software Testing Improvements
JetBrainsは、今までアーリーアクセス版として提供していたAIコーディングエージェント「Junie」を一般公開し、同社が提供するIDEの全ユーザーが利用可能になったことを発表しました。 JetBrainsは、コードの補完やプロンプトによるコード生成などを行うコーディングアシスタントの「JetBrains AI Assistant」と、自律的にコードの生成や修正、テスト作成などを行うコーディングエージェントの「Junie」の2つを、主に同社のIDEと統合されたAI機能として提供しています。 Junieは今年（2025年）2月にJetBrainsから発表され、アーリーアクセス版として提供されてきました。 参考：JetBrainsも自律的にコーディングを行うAIエージェント「Junie」を発表 JunieはReadmeなどを読んで自律的にコードを生成可能 Junieは、既存のコードの文脈や
こんにちは、株式会社ACES でテックリードをしている奥田(@masaya_okuda)です。 AIエージェントを活用し、自然言語による指示を中心にコーディングする手法が注目を集めています。特にゼロからコードを書く場面では、その効果の高さは多くの現場で実感されているのではないでしょうか？ 私たちもこの可能性に注目し、AIコードエディター「Cursor」をフルタイムの開発チームメンバー全員に導入。日々の開発でAIエージェントの活用を積極的に進めています。 一方で、既に運用中のサービスを開発しているチームにとっては、既存コードの文脈を理解させた上でどう活用するかが大きなテーマとなります。本記事では、そうした既存コードのコンテキストを踏まえたAI活用の実践について紹介します。 開発チームの前提と課題 私の所属する開発チームはAI議事録ツール「ACES Meet」を開発しています。このプロダクトは
現在のクラウド時代において、多くのアプリケーションがWeb上で動作し、シングルサインオン（SSO）にも対応しています。しかし、自社で開発したアプリケーションにSSOを実装しようとすると本格的な改修が必要となり、それに伴う相応のコストが発生します。 本連載では、Entra IDとSAML認証を使用して、アプリケーションを改修せずにSSOを実装する方法について説明します。これは、既存のアプリケーションを手早くSSO対応させたい場合に役立つ手法です。 初回となる今回は、最低限抑えておきたいSAMLの基本要素について確認をしたいと思います。 SAMLとは Entra IDとSAMLのAssertion テストサイトでSAMLをテストする テストAPにてテストに必要な情報を取得する Entra IDにテストAPの情報を登録する IdP(Entra ID)とSP(テストAP)の関連付けを行う テストA
この記事は、CYBOZU SUMMER BLOG FES '24 (Frontend stage) DAY13 の記事です。 こんにちは、フロリアでエンジニアとして活動している hacchan です。 現在 kintone ではフロリアというプロジェクトの中で、Closure Tools から React への移行作業に取り組んでいます。 以前、そのフロリアのチームの 1 つである Reactone チーム が Storybook をフル活用してテストを実装した話 を紹介しましたが、今回はそのアフターストーリーを紹介します。 Storybook のフル活用はやめた 以前の Reactone チームでは、Storybook の Test Runner を使って、Integration Test を実行するなど、Storybook をフル活用してテストを実装していましたが、新たな領域の刷新を開
読者の皆さんは、テストについてどのようなイメージをお持ちでしょうか。「開発の後に行う確認作業」といったイメージを持たれている方もいるかと思います。 しかし、開発しようとしているソフトウェアに不具合の混入を防ぐには、もっと早い段階でテストについて考えることが必要です。こういったテスト活動は、プログラムを1文字も書いていないときから始めることができるのです。 本記事では、2016年に提唱された継続的テストモデルを紹介しつつ、アジャイルとも親和性のあるシフトレフトなテスト活動について解説していきます。 DevOpsにおけるテストの考え方 DevOpsのループ図とは何か？ 継続的テストモデルとは何か 継続的テストモデルにおいてテストは「活動」である シフトレフトなテスト活動とシフトライトなテスト活動 シフトレフトなテスト活動としてのテスト駆動開発 コード実装を始める前から行うテスト活動 シフトレフ
こんにちは、クラウド&ネットワークサービス部の福岡です。 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 {
このサイトについて: 本サイトは、GitLab認定パートナーの「クリエーションライン株式会社」が「GitLab公式ドキュメント」を日本語に翻訳して一般公開しているものです。GitLab社は本サイトの運営に関与しておりません。公式情報や最新の更新については、必ず「GitLab公式ドキュメント」をご確認ください。本サイトに関するご質問やフィードバックは、「クリエーションラインのお問い合わせページ」までどうぞ。皆様の声をお待ちしております。本サイトは2023年8月時点(GitLab 16.3)の情報を元に翻訳しております。更新情報については定期的にご確認をお願いいたします。機械翻訳を使用しており、誤訳や難解な表現があるかもしれません。改善のためのリソースが限られているため、ご理解をお願いいたします。お知らせ: Tech関連記事（アジャイル＆DevOps、クラウドネイティブ、データマネジメント、生
この記事は MICIN Advent Calendar 2023 の24日目の記事です。 前回はSaneさんの「データ基盤チームで社内インターンをやってみて」でした。 はじめに abekohです。MICINでMiROHAの開発をしております。 本記事では、書籍等から得た設計・実装パターンの知識や、実際にプロダクト開発で試して得られた経験などから編み出した、開発効率向上のためのWeb API開発のプラクティスを紹介します。 筆者が関わっているMiROHAは治験の業務支援を取り扱うプロダクトです。MiROHAの開発における特性として、以下のようなものが挙げられます。 治験業務に関するドメインが特有で複雑 前例が少なく、MVPを追求中。プロダクトのアプローチが頻繁に変わる 外部品質は高い水準が求められる これらの特性を意識して開発を促進させるために日々試行錯誤しております。 複雑なドメインに対す
アジャイル型の開発が導入されていない現場であっても、そして一人であっても、実践可能なアジャイルに関するプラクティスは存在します。 例えば、自動テストや、テストファースト、テスト駆動開発（TDD：Test Driven Development）です。ユニットテストフレームワークを使ってテストコードを書いて開発しながらテストを実行する「自動テスト」、実装の前にそのテストコードを書く「テストファースト」、テストと実装を繰り返しながらインクリメンタルに設計・開発を行うのが「TDD」。これらプラクティスのなかで、はじめの一歩となるのが自動テストですが、1人で実践するには、どこからはじめるか、どうテストを組み立てればよいのか、あるいは自分のテスト方法は適切なのか、不安を持つこともあるでしょう。 そこで本稿では、さまざまなチームや組織へのテスト手法の導入を支援し、精力的に講演や執筆などを行ってきたこの分
はじめに みなさん、DRY原則はご存知でしょうか？ DRY = Don't repeat yourselfの略で「繰り返しを避けること」という意味ですよね。 良いコードを書くための重要かつ基本的な原則なので、みなさんよくご存知だと思います。 ですが、DRY原則はテストコードを書く場合は必ずしも最善にはならない場合があります。 他の人が書いたテストコードを見ていると、テストコードにDRY原則を適用したために、かえって悪いコードになっているケースをときどき見かけます。 この記事ではなぜテストコードをDRYにすると良くないのか、ということを説明します。 追記：タイトルを変更しました @t_wada さんのコメントを受けて、タイトルを見直しました。 「テストコードはDRYを捨ててベタ書きする」 => 「テストコードの期待値はDRYを捨ててベタ書きする」 【注意】この記事は画一的なテストコードの書き
こんにちは、SWETグループの田熊です。 現在SWETグループでは書籍「単体テストの使い方/考え方」の輪読会を実施しています。 輪読会ではメンバー同士で活発に意見が交わされていますが、著者の主張に疑問を感じる箇所もあり、一度グループ外の方とも意見を交換したいと考えていました。 そこで、t_wadaさんをお招きし「単体テストの使い方/考え方」についてディスカッションする機会を設けました。 本記事では、SWETメンバーとt_wadaさんとのやりとりを紹介したいと思います。 ディスカッションの流れ ディスカッションは事前にSWETグループのメンバーが書籍を読んで疑問に感じたテーマを挙げてもらい、t_wadaさんの意見を聞くという流れで行いました。 今回は次のテーマについて話をしました。 「退行に対する保護」があるテストとはなにか 「リファクタリングへの耐性」のトレードオフはあるのか 統合テストの
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
Qiita Conferenceは、ソフトウェア開発者が集まり、最新の技術や最先端の挑戦・ソフトウェアの未来についての考えや知見を共有し、つながる場を創出する、「Qiita」が開催するオンライン技術カンファレンスです。ここで和田卓人氏が「サバンナ便り - 自動テストに関する連載で得られた知見のまとめ（2023年5月版） 」をテーマに登壇。続いて、自動テストのテストサイズについて話します。 自動テスト内の分類基準は明解ではない和田卓人氏：次に、テストサイズという考え方にいきます。自動テストにも「〇〇テスト」というやつがいろいろあるんですよね。 特に我々ソフトウェアエンジニアにとって馴染み深い名前はユニットテストとか、単体テストとか、インテグレーションテストとか、システムテストとか、エンドツーエンドテストとか。「〇〇テスト」というやつがいろいろあります。それらの分類基準は、実は言うほど明解では
GitHub Copilotとの単体テストがやばい。ChatGPTが書いてくれるテストもすごい。もうこれらがない時代には戻れないような気がします。 こんにちは。AWS事業本部コンサルティング部に所属している今泉（@bun76235104）です。 みなさんユニットテスト書いてますか？ 昨今AIがダミーデータを書いてくれたり、ユニットテストそのものを書いてくれたりと技術の進歩がすごいですね。 私はリファクタリングが好きですが、リファクタリングをする前に絶対に必要なもの。 そうテストですね。 今回私がテストを後回しにしてしまった以下のOSSについてGitHub CopilotとChatGPTのそれぞれの力を借りながら、テストを書いてみました ※ これは以前私が始めたプロジェクトであり、OSSとして公開されているので学習に使われても問題のないコードです。 なお、GitHub Copilotの料金や
ビジネスを変革するフロントエンドの祭典としてモダン開発組織の構築ノウハウをはじめ、2022年現在の開発トレンドを多角的にラインナップした「POST Dev」。日本のフロントエンド開発を牽引するゲストを招き、これまでのテストの歴史を振り返りながら、その必要性や開発組織に浸透させるメリットをはじめ、これからのテストの可能性についてディスカッションを行いました。全4回。1回目は、フロントエンドテストの歴史について。 セッションテーマはフロントエンド開発テストの「必要性」と「歴史」古川陽介氏（以下、古川）：さて、次のパネルディスカッションは、「フロントエンド開発テスト最前線」というタイトルで発表していこうかなと思います。 ご登壇いただくのは、タワーズ・クエスト株式会社取締役社長の和田卓人さんです。和田卓人さんはリクルートの技術開発の技術顧問をやっています。 また、株式会社リクルート兼株式会社ニジボ
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 作ったものが想定した動作をしているか。 それを確認するために、テスト（試験）を行います。 検証したいことがちゃんと実現できて確認が取れているのであれば、その品質自体は割と気にされないことが多い印象です。 保守・運用・追加開発 をしていくプロジェクトが多くあると思います。 その作業の中で、改善を取り入れていくこともあると思いますが、その中でも一番後回しにされるのが、テストコードの改善のように思います。 推測ですが、「コストによるメリット・リターンが少なすぎる」ことが理由かな…と（開発者目線ではリターンが大きいのですが、運用者目線ですとリタ
スペースマーケット所属のfumink7です。 北欧へのあこがれが高まっています☃️ ReactでのWebアプリケーション開発をはじめる中で、ユニットテストを書き始めたときに知って役立ったtipsをまとめてみました。 テスト環境 テスティングフレームワークはJest、UIテストのためにTesting Libraryを使用しています typescript@4.9.4 React@18.2.0 [email protected] @testing-library/react@13.3.0 ①アサーション 特定の要素内に絞って要素検索を行う - within getBy、findByなどで「要素A内にある要素Bを取得する」場合にwithinを使って要素Aを指定することができます。 const formElement = screen.getByRole('form') expect( within(formE
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
