2022年9月9日 日本科学技術連盟 ソフトウェア品質シンポジウム2022(SQiP2022)
こんにちは。BASE BANK 株式会社 Dev Division にて、Engineering Manager をしている東口(@hgsgtk)です。 TL;DR 第 17 回 Ques にて「CI のためのテスト自動化」というテーマでの登壇依頼をいただき「Agile Testing を夢見たテスト自動化 〜ATDD への挑戦から始まる 1 年間の試行錯誤〜」というタイトルで発表しました 実際にうまく行かなかったことも含めてテスト自動化のしくじりを話しました Agile Testing・ATDD/BDD/SBE に興味がある方に参考になる資料を公開しました 第17回Quesとは Ques とは Software 品質保証に関わる QA エンジニアの活性化を目的とした QA 専門イベントです。 ques.connpass.com Software品質保証に関わるQAエンジニアの活性化を目的
Mockito や gomock が使いやすいせいか、単体テストというのはモックするものである、という思い込みがあるのか、人々がモックしすぎているのを時折みかける。 モックは必要悪で、しないにこしたことはない。外部の API サーバーとかはガンガン叩くわけにもいかないけれど、ファイル読み書きくらいは、実際にファイルを作ったり消したりしてしまっていい。/etc/passwd を消すとか、1GB のファイルを作るとかだと難しいかもしれないけれど、その場合でも、パスのプレフィックスを指定できるようにして、一時ディレクトリの中の etc/passwd を使うとか、ファイルサイズを指定できるようにするとか、逃げ道はいくつもある。そこを飛ばして「ファイル操作は一律モックしましょう」とか頑張りだすと辛いことになりがちだ。 モックの一番の問題は、本番とテストで違うコードが走ることで、これは自動テストの価値
2021/09/13 Open8 で発表したフロントエンドテストプラクティスの話です。
以下のイベントの投影資料です。 https://confengine.com/conferences/scrum-fest-osaka-2021/proposal/15337 お問い合わせは https://twitter.com/nihonbuson まで。 【発表資料中のURL】 P…
アジャイル開発研修の中で、ソフトウェアテストってなぜやるの?誰がやるの?って話をしたときの資料です。
こんにちは、Androidチームの田熊(fgfgtkm)と外山(sumio)です。SWETのAndroidチームでは、Androidのプロダクトに対して自動テストのサポートをしています。 この度株式会社Mobility Technologiesが提供するタクシーアプリ「GO」のAndroid版に対する、おおよそ2年間に渡る取り組みが終了しました。 本記事では、この取り組みで行ってきた次の2点を紹介したいと思います。 「GO」のAndorid版に対してどのような自動テストを導入したか 開発チームに自動テストを定着させるまでにやったこと タクシーアプリ「GO」に対しての自動テスト導入 SWETのAndroidチームは「社内のAndroidエンジニアが自動テストを書くことを習慣化している」ことをゴールの1つとして、自動テストを普及させるための取り組みをしています。 その中でAndroidのテスト
ContentsBasic project setupThe basic setup consists of four steps: Create the project and source directoriesCreate a package.jsonGet a .gitignore, tsconfig.json, .eslintrc.jsInstall TypeScript & dependenciesNote: This guide uses yarn, but if you prefer npm it has similar commands. # Create project folder mkdir my-project cd my-project # Create source folder and files mkdir src touch src/main.ts sr
この記事は 3/27 に開催されたCAMPHOR- DAY内で発表した内容を元にした記事です。 アーカイブはこちら(共有してるスライドの画面が黄色くなっていることは終わってから知りました🥺) この記事では gomock や mockgen の基本的な使用方法から、 gomock の内部の動きまでを紹介します。この記事を読み終わったあなたは思わずgomock 完全に理解した と言っていることでしょう。 基本的にGoの文法を知っていればgomock自体を知らなくても理解できるような説明にしているつもりです。 この記事ではv1.5.0の仕様をもとに話しています。 golang/mock(gomock) とは go 公式が出しているインターフェース定義からモックの生成を行うことができるライブラリです。 生成したモックを扱うパッケージも含まれます。 この先の説明では gomock と呼ぶことにしま
2021-01-19 React, tddTDD in a React frontendNowadays, only a few professional developers are left that seriously doubt the value of test-driven-development and test-driven-design (tdd). But the reality of many codebases I have seen is that tdd is often limited to the backend, where the "business logic" lives. Part of this is due to a stigma that frontend development is not "real software developme
はじめに Haskellでテスト駆動開発を行う際、純粋な関数は単体テストを書きやすいですが、 返り値がモナドの関数(この記事ではそのような関数をメソッドと呼びます)にたいして単体テストを書くのは簡単ではありません。 今回、メソッドに対して単体テストを書きやすくなるライブラリ methodを作成しました。 methodとは methodでは a1 -> ... -> an -> m b型の関数のことをメソッドと呼びます。 ここでmはモナドです。(->) rモナドを除く大抵のモナドはサポートしていますが、独自のモナドをメソッドにするにはMethod型クラスを実装する必要があります。 モックの作成 methodでは任意のメソッドのモックをDSLで書くことができます。 import Test.Method import RIO (throwString) f,f' :: Int -> String
ソフトウェアテストシンポジウム 2020 新潟 JaSST'20 Niigata 基調講演 2020年9月28日(月) http://www.jasst.jp/symposium/jasst20niigata.html
Transcript ςετίʔυ͕૿͑ΔͱόάݮΔͷͩΖ͏͔ʁ�� ʮ���ˠ������ʯͰݟ͑ͨੈքͷ� גࣜձࣾ;0;0ςΫϊϩδʔζ� ;0;0508/෦�J04νʔϜ� ໊औ�߂ฏ Copyright © ZOZO Technologies, Inc. © ZOZO Technologies, Inc. גࣜձࣾ;0;0ςΫϊϩδʔζ� ;0;0508/෦� J04νʔϜ ໊औ�߂ฏ 20192݄ΑΓݱ৬ɻ ZOZOTOWN iOSΞϓϦͷ։ൃΛ͍ͯ͠·͢ɻ झຯͰݸਓ։ൃɻ 2 © ZOZO Technologies, Inc. 3 ���ˠ������ ʹ ͜ͷ�΄ͲͰ૿Ճͨ͠ςετΧόϨοδͷׂ߹ © ZOZO Technologies, Inc. 4 ���ˠ������ ����� ˞ܭଌର͜ͷ�ͷ։ൃͰؔ༩ͨ͠ϑΝΠϧʹߜ͍ͬͯΔ © ZOZO Te
この文章の背景 この文章はプライベートメソッドのテストを書くべきか否かに関する knsmr さんのご質問に対して 2013/03/13 に QA@IT で回答したものです。残念ながらQA@IT のサービス終了(2020/02/28)と共にアクセスできなくなってしまったため、運営を行っていたアイティメディア株式会社様、開発を行っていた永和システムマネジメント様、そして質問をされた knsmr さんに許可とご協力をいただき、当時の回答をサルベージしてブログに転載する運びとなりました。 プライベートメソッドのテストはよく議論になるテーマですので、当時の回答を再編集し、knsmr さんのご質問も含め、ご利用いただきやすいライセンス CC BY(クリエイティブ・コモンズ — 表示 4.0 国際 — CC BY 4.0) で公開いたします。 目次 この文章の背景 目次 knsmr さんのご質問 私の回
なんか2週間くらいずっと画面単位のテストを単体テストと呼んで、手動テストをする現場についていろいろ文句がSNSで流れていた。それについて思うことをバカスカ書く。 これは、誰かを批難したいわけでもなく、ただの感想である。言うなれば街の風景をみたときの日記だ。そうだよ。これは日記だよ? 要約 だいたいの話は僕が2,3年前にTwitterで言いまくった単体テスト/結合テストなんて存在しない - Togetterまとめに似ていると思ったけど、僕の狭い観測範囲では生産的な結論を迎えずに文句の固まりで終わって、こう非常にあーあっていう気持ちが残った。 あと、観測結果として 同僚や上司に加えてkyon_mmに「なぜその手法でテストをしたいの?ねぇ?なんで?」って聞かれても答えられるか。が相手を評価する目安だと僕自身が自覚した。 というのが大きかった。 単体テスト まず、最初に思ったのはTwitterで文
TDD/BDDにおける「振る舞い」の意味するところとは何なのか:いまさら聞けないTDD/BDD超入門(3)(1/3 ページ) 前回の「TDD/BDDの思想とテスティングフレームワークの関係を整理しよう」では、TDD/BDDについて、その思想と、それをサポートするテスティングフレームワークに分けて解説しました。その中で、TDD/BDDについては実際の熟練者の言葉を借り、テスティングフレームワークについては概要を触れて、その系譜をたどりました。 BDDはその名前に「Behavior」とありますが、「振る舞いとしてのテストコードを書く」とはどういうことなのでしょうか? 難しく考え過ぎる必要はありませんが、「それは振る舞いを書いていないよ」と指摘をする熟練者が何を考えているかを理解することはBDDを習熟していく中で重要な意味を持ってきます。 本記事では「振る舞い」という言葉がどのような意味で使われ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く