gRPCと手動テスト | メルカリエンジニアリング
この記事はMERPAY TECH OPENNESS MONTHの5日目の記事です。 merpayでNFC決済のmicroservice (nfc-service) を開発担当している @Hiraku です。メルペイのバックエンドシステムは、各microserviceが主にgRPCを主な通信プロトコルとして用意しています。当然、各チームはgRPCサーバーを開発しています。この記事では、ちょっとした開発の日常をお見せしたいと思います。 とあるエンドポイントの場合 そもそもgRPCサーバーだけで、iOS/Androidのバックエンドができるのか？と思う方がいるかもしれません。 下図は、典型的なリクエスト経路を示しています。 merpay-gateway … 主にプロトコルの変換を担う merpay-api … BFF(Backend for Frontend)的な役割を担い、他のmicroser
PHPerがRailsデビューしてWebAPIを作りRSpecでテスト書いてCap3/CircleCIでデプロイして分かった事を1ヶ月前の自分に教えたいので、まとめてみた - Qiita
PHPerがRailsデビューしてWebAPIを作りRSpecでテスト書いてCap3/CircleCIでデプロイして分かった事を1ヶ月前の自分に教えたいので、まとめてみたRubyPHPRailsRSpec タイトル長い。すまぬ。PHPerとして約10年近く。Ruby自体は案件によってちょこっとだけ触ったことがある程度。Rails自体を本格的にさわるのは今回が初めて。PHPだとCakePHPを中心にZend／Symfonyなどいくつか。そんな僕が今回、Rails4デビューをして、WebAPIを作り、RSpecでテスト駆動開発風味で、GitHubプルリクベースの、CircleCI経由デプロイをするまでの開発の流れをひと通りやってみて、分かったことがいくつかあったので、それをまとめてみた。過去の自分のために。 注意点としては、今回作ったのはWebサービスではなく、スマホゲーム（ネイティブ）のサー
フリーエンジニアのIT案件ならレバテックフリーランス
2016年11月3日（祝）、大田区産業プラザPiOにて開催された国内最大のPHPイベント「PHPカンファレンス2016」。レバテックフリーランスでは、カンファレンスセッションの登壇者のひとり・和田卓人氏にインタビューを実施しました。 テスト駆動開発の先駆者として知られる和田氏ですが、今回の講演テーマは「PHP7で堅牢なコードを書く-例外処理、表明プログラミング、契約による設計」。あえてテスト以外のテーマを設定した理由をはじめ、PHPの優位性や今注目している言語、初心者エンジニアへのアドバイスなど、幅広くお話を伺ってきました。 ＜この記事の要約＞ 1. PHPの良い点は、ゆるふわな言語に見せかけて堅牢なコードも書けるところ。悪い点は、覚えることが多くて難しいところ。 2. テストを書いていればコードの品質が高いわけではない。また、テストが書けないくらい問題を抱えたコードでも、中から改善してい
単体テスト項目書を書くのに、守らなかったら自殺すべき3つの原則 - @ledsun blog
1.テスト項目書を書くときは用語集を作ること 用語集を作れば 表記ブレを防げる 重複を減らせる 毎回説明を記述する必要がなくなるので全体はコンパクトになる。 テスト実施者に重複した内容を何回も読ませる奴はDRY原則をわかってない、自殺すべき。 2.ユースケースシナリオと単体テストの項目が合ってないのはどっちかがおかしい ユースケースシナリオと単体テスト項目の内容がずれていたら「正しい仕様」を確認する。 ログインに失敗したときのメッセージが ユースケースシナリオでは「パスワードを確認してください。」 単体体テスト項目では「IDとパスワードのいずれかが間違っています。」 と書いてあったら？メッセージが出ているのだからテストに合格したと判断するのはダメ。 仕様もテスト項目も確認しないでリリース直前に「これおかしくないですか？」とかドヤ顔言うやつは、自殺すべき。 3.ユースケースは能動態で試験項目
177bdf6352de463fdc87
経験ゼロでもできるプログラミング現場の単体テストを読んだので、そのまとめ はじめに 著者曰く、 初めて導入する単体テストの指南書 を目指した一冊。 単体テストを書いたことが無かったり、書いたことがあっても書き方の方針が定まっていない人にはおすすめの本。 逆に既にバリバリテストコードを書いてる人に、再確認的な内容になるかも。 単体テストについて基礎知識 アプリケーション開発では設計に時間がかかりすぎて、テストに時間をかけられないことがある。 致命的な障害発生する可能性がある。 とはいえすべてを想定してテストを実施することはできない。 テストケースを絞る必要がある 各テストフェーズの礎となる単体テストが重要になる 高品質なシステム ユーザーを満足させ、不安や不満をいだかせないこと システムエラー：データの破損などの心配が生まれる 応答が遅い：いらいら・二度と使わなくなる まとめてテストはダメ
試験表の作り方 - Qiita
はじめに （ここで言う）試験表とは、ソフトウェアの試験項目をExcelにまとめ、テスターが実施時にPASS, FAILを記入し、後から試験結果を参照できるようにしたものである。 Qiitaにはプログラマ層の投稿は多いが、この層の投稿は少ないように見受けられたので、記事を書いてみることにする。 過去の投稿を見ればわかるが、私はこの道（つまり品質保証の）の専門家ではない。おかしなところがあれば、コメントにどんどんツッコミを入れてほしい。 項目の列挙 最初にExcelを開いてはいけない。まずはテキストエディタ（メモ帳）を開こう。 試験したい項目をリスト状に列挙する。中項目・小項目があれば bullet の数を増やすなりインデントするなりして、なんでもいいので列挙する。 本当なら「どのような観点でこの項目を挙げたのか」があると良いのだが、一朝一夕にできるものではないと思っているし、ここで議論できる
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
