テストプロセスを詳細化した話 - レビュー・テスト分析 - Qiita
以前、シフトレフトのために静的テスト、動的テストの2つのアプローチからどんなアクションを取れるかを記事にしました。 上記記事で書いたように、以前までのwith QAチームではテスト設計以降の作業を重視せざるをえず、上流工程でのテスト活動を明文化できていませんでした。しかし、メンバーの増強とユニット制への体制移行により、より上流工程から積極的にQAが関わっていけるようになりました。 その中でQAとして何ができるとよいのかを考えた結果、より積極的にテスト活動が行えるようテストプロセスを詳細化することにしました。具体的にはwith QAチームでは新たにレビューとテスト分析をテストプロセスとして明示することになりました。1 今回は、このレビューとテスト分析を中心に、実際に何が変わったのかを書いていきます。 前提の確認 本題に入る前に、レビューとテスト分析とは何かという確認から行います。 「レビュー
LaravelでHTTPテストを実装しました - WHITEPLUS TechBlog
はじめに こんにちは、ホワイトプラスのコアシステム開発Gのエンジニアのyamauchiです。 今回、新たにHTTPテストを実装したため、実装時に発覚した問題とその解決法を共有したいと思います。 HTTPテストとは HTTPテストとは、擬似的なHTTPリクエストを生成し対象のエンドポイントに投げ、返却されたレスポンスが期待したものかチェックするテストです。 背景 現在、コアシスが担当しているシステムでは、手動でテストを行う余地が残されており、リファクタリングを積極的に進める現状では、安全性や効率性をより高めたいという背景がありました。 そのためリグレッションテストの自動化を進め、手動で確認する割合を減らしたいと考えています。 ただし、無闇にテストの数を増やすのではなく、テストピラミッドのルールに従って効率的かつ効果的なテストを作成していく方針です。 実装方法 弊社のシステムではPHPのフレー
UIテストの所要時間を10分の1にする試み、Raspberry Piのクラスタで並列実行。ソフトウェア品質シンポジウム2018
UIテストの所要時間を10分の1にする試み、Raspberry Piのクラスタで並列実行。ソフトウェア品質シンポジウム2018 開発現場の多くでテストの自動化が進む中で、テスト時間を短縮することはビルドとテストの待ち時間を減らし、開発効率を高める上で重要なポイントになってきています。 そうしたなかで時間がかかっていたUIテストの所要時間を短縮する手段としてRaspberry Piをクラスタ化する手法を紹介するのが、レバテック株式会社 折田武己氏です。 本記事では、9月12日から14日のあいだ東洋大学で開催された「ソフトウェア品質シンポジウム」（日本科学技術連盟主催）での折田氏のセッション「UIテストの所要時間を10分の1に短縮する取り組み～ラズベリーパイのクラスターで並列実行～」の内容をダイジェストで紹介します。 単体テストはさくさく終わるのにUIテストは時間がかかる レバテック株式会社
静的型チェックがあったらテストはあまり書かなくて良いのか - $shibayu36->blog;
昔に動的言語だとひたすらテストを書かないといけないけど、静的型チェックの仕組みがあればそんなにテストを書かなくてもいいよねみたいな話があった記憶がある。昔は結局どうなんだろうと思ってたのだけど、最近もそういう話を耳にして、やっぱりそんなことないだろうという気持ちになったのでメモ。ふと思いついただけなので正当性は分からない。 まずなぜそのような話になるのか考えたのだけど、「静的言語ならコンパイル時に型チェックをすることができるため安全性を高められる」という点からこういう話が上がってきているように思う。しかしよく考えてみると、静的型チェックという仕組みは、プログラムテキストとして正当であるかという点しか保証していない。つまり、特定の変数が必ずその型であるとか、特定のエンティティからのメソッド呼び出しが正しいか(メソッド名や引数など)とか、関数が返す型がかならず指定した型になるかとか、そのような
Rails でテストをどう書くべきか備忘録
今朝聞いた今週の rebuild.fm のポッドキャストで、テストに関する話題がとても面白く勉強になりましたので備忘録メモ。全部テスト書いてたら時間が足りないし、個人的にはどの部分を重点的にテストすべきか、削っても良いのはどこかに注目して聞きました。 Rebuild: 43: Kent is More Professional (Kenn Ejima) 以下 rebuild.fm 話題から参考にしたいメモ ・テスト書くのは良いが、テスト原理主義、100％カバー、全部テストファーストにこだわるのは疑問。 ・内部構造、実装に対するテストは書かない。 ・モックは一番外側のAPI、インターフェースに対してだけ使う。（※） ・モックのためのモックとかは避ける。 ・リファクタリングのためにテストを書き換えなきゃいけないようなテストは駄目。 ・テストとコードを同時に変更すると、トラブルに気付きにくくなる
ペアプログラミングして気がついた新人プログラマの成長を阻害する悪習
最近、あまりプログラミングが得意でない人のサポートをする形で、長い時間にわたってペアプログラミングを行っている。そのなかで、気がついた悪い習慣と成長するための良い習慣というものをまとめてみる。 この記事のバックグラウンドとなる体系的知識が本になりました。 エンジニアリング組織論への招待 ～不確実性に向き合う思考と組織のリファクタリング あわせて読みたい 経営者マインドが足りない！vs. 現場に任せてくれない！の対立をなくすカードゲームをつくった話 新人プログラマに知ってもらいたいメソッドを読みやすく維持するいくつかの原則 新人プログラマに知っておいてもらいたい人類がオブジェクト指向を手に入れるまでの軌跡 ペアプログラミングして気がついた新人プログラマの成長を阻害する悪習 あきらめるにはまだ早い！ソースコードの品質向上に効果的なアプローチ 心理的安全性ガイドライン（あるいは権威勾配に関する一
卜部昌平のあまりreblogしないtumblr
前回の続き。 前回の時点では「git blameが密になっているところはきっと活発に編集されていたに違いない」という仮説があったわけですが、これは本当のところは、よくわからない。なぜかというと、blameというのは地層のように降り積もったコミットの表面に露頭してるところしか見せてくれないわけです。本当に活発に更新されていたかを知るには、ようするに地質平面図じゃなくて地質断面図が必要なわけ。分かりますよね。 で、それはどうやって作ればいいかというと、gitには便利なgit log -pという、こういうとき便利だけど普段は使い道のなさそーなコマンドがあって、これは生のdiffをすべてだらだらと表示してくれるわけですよ。で、diffからblameを再構成するにはdiffの+行をひたすら集めてくればいいわけだけど、その時-行も一緒に覚えておいて、あるコミットでどのコミットが上書きされたかを覚えてお
パラメータの正当性検査とユニットテストのカバレッジ | DevelopersIO
渡辺です。 最近はユニットテストの導入方法などに関するエントリーが多かったので、今回は実用的な小ネタとして、メソッドにおけるパラメータの正当性検査とユニットテストについて紹介したいと思います。 パラメータの正当性検査 はじめにパラメータの正当性検査について復習しましょう。Javaプログラマであれば読んでないことが許されないEffective Java（第2版P.175、ただし絶版）には次のように記述されています。 ほとんどのメソッドとコンストラクタは、パラメータとして渡される値に関して何らかの制約を持っています。たとえば、インデックス値が負であってはいけないとか、オブジェクト参照がnullであってはいけないというのが普通です。このような制約は明確に文書化すべきであり、メソッド本体の初めに検査することで制約を強制すべきです。これは、エラーが発生したらできるだけ速やかにエラーを検出するようにす
DevOpsなんてくそくらえ - razokulover publog
先日こんなことを言われた。 「テストを書いた成果を見せよ」 と。 ショッキングだった。 経緯 わたしはいまレガシーなコードに囲まれている。 もちろんテストもほとんどないピカピカのレガシーちゃんである。 レガシーちゃんは「Ctrl+F5 & tail -f 駆動開発」により開発が進められており、日々進化している。 このまま進化をつづけるといつかモンスターになり(もう軽く怪獣っぽいが)、開発スピードがどんどん遅くなり、メンテナンスやバグつぶしでエンハンスとなるような開発ができなくなる。このままじゃマズい...。 こういった事態を一新すべく、手探りながら私含め数人の先輩たちで「DevOps」に取りかかることになった。 バズワードにもなっているが「DevOps」とは、 従来型のシステム管理や調達（ITILを含む）といった、保守的でプロセスを中心に据えた運用からよ>り戦略的でアジャイルな、そして自動
Webアプリのパフォーマンスをチェック·Bucky MOONGIFT
Buckyはnode/JavaScript製のオープンソース・ソフトウェア（MIT License）です。 Webアプリケーションを提供していて気になるのはパフォーマンスです。ストレスにならないレスポンスが維持できているかどうか、それをWebブラウザでモニタリングできるのがBuckyです。 グラフはリアルタイムに更新されていきます。 アクセスがあるたびにグラフが変わっていきます。 BuckyはJavaScriptファイルを読み込むことでページのロードとAjaxリクエストをモニタリングするようになります。そしてレスポンスタイムをBuckyサーバに送信します。そのデータはリアルタイムに監視し、ビジュアル化されたグラフを描けるようになっています。 最近ではAjaxを使うのが当たり前になっており、クローラのことを考えなければデータを非同期で取得することで表示を高速化し、頻繁に変わるコンテンツを除外
Etsy Engineering | LXC - Running 14,000 tests per day and beyond! (Part 1)
Continuous Integration at Etsy As Etsy continues to grow and hire more developers, we have faced the continuous integration scaling challenge of how to execute multiple concurrent test suites without slowing the pace of our deploy queue. With a deployment rate of up to 65 deploys / day and a total of 30 test suites (unit tests, integration tests, functional tests, smokers...) that run for every de
ブラックボックステストとホワイトボックステスト | DevelopersIO
テスト分類のひとつにブラックボックステストとホワイトボックステストがあります。 ブラックボックステストとは、テスト対象の内部を意識せずに外部仕様のみからテストケースを構築していく手法です。ユニットテストであれば、テスト対象となるメソッドの実装（コード）を意識せず、メソッドのAPI仕様からテストケースを作成することになります。 一方、ホワイトボックステストでは、テスト対象の内部を意識し、どのような構造であるかを踏まえたテストケースを構築します。ユニットテストであれば、テスト対象となるメソッドの実装（コード）を意識し、分岐や繰り返しなどを考慮しつつテストケースを作成することになります。 さて、ユニットテストはブラックテストでしょうか？ それともブラックボックステストでしょうか？ 「JUnit実践入門」では次のように記述しました。 本書で扱うユニットテストは、テスト対象の内部ロジックを考慮して行
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Helompo > Situs Slot No#1 Bet 100 Perak Server Mpo Terbaru 2024
ブラウザ横断で JavaScript のテストを自動化する BrowserSwarm