Go言語でのテストの並列化 〜t.Parallel()メソッドを理解する〜 | メルカリエンジニアリング
この記事は、Merpay Tech Openness Month 2020 の6日目の記事です。 メルペイでBackendエンジニアをしている柴田（@yoshiki_shibata）です。この記事では、Go言語のtestingパッケージに用意されている並列化の機能について説明します。 Go言語では、テストコードを作成するためのtestingパッケージが用意されています。一般に開発するソフトウェアの規模が大きくなるに従って、作成されるテストコードの量も多くなり、すべてのテストが終了するまでの時間も長くなっていきます。特に、データベースへアクセスするようなテストでは、データベースへの通信時間がテスト時間の多く占めますので、テストコードを逐次実行するよりは並列実行することで、テスト時間を短縮できます（厳密には用語「並行」ですが、t.Parallel()メソッドの説明なので、この記事では用語「並列
プライベートメソッドのテストは書かないもの？ - t-wadaのブログ
この文章の背景 この文章はプライベートメソッドのテストを書くべきか否かに関する knsmr さんのご質問に対して 2013/03/13 に QA＠IT で回答したものです。残念ながらQA＠IT のサービス終了（2020/02/28）と共にアクセスできなくなってしまったため、運営を行っていたアイティメディア株式会社様、開発を行っていた永和システムマネジメント様、そして質問をされた knsmr さんに許可とご協力をいただき、当時の回答をサルベージしてブログに転載する運びとなりました。 プライベートメソッドのテストはよく議論になるテーマですので、当時の回答を再編集し、knsmr さんのご質問も含め、ご利用いただきやすいライセンス CC BY（クリエイティブ・コモンズ — 表示 4.0 国際 — CC BY 4.0） で公開いたします。 目次 この文章の背景 目次 knsmr さんのご質問 私の回
20年物のC言語で作られたシステムのテスト工程を改善しようとした話 - Qiita
はじめに ちょっと前に20年物のC言語で作られたシステムのテストを色々改善しようとしてみたので、この時に得たちょっとした知見を書いていこうと思います。 ※注意 記事を書くために自分のパソコンで当時を思い出しながら環境を作っているので、実際、実務でやった環境やバージョンとは違います。 また、この記事にはいくつかコードがでてきますが、すべて記事を書くために考えた疑似的な例にすぎません。 単体テスト用のテストコードの作成 20年も動いているシステムだと、もはや誰にも意味はわからんが、既存の挙動を変えてはいけない箇所がいくつもあります。 そういう箇所に手を入れざるを得ないときに、有効な方法として以下のような方法があります。 まず、既存のコードに対するテストコードを記載します。そして全て合格することを確認してから、少しづつ機能を拡張していきます。 これにより、新規機能追加が既存の機能を壊していないこ
プログラマーテストの原則 by Kent Beck
チョコレート対バニラTDD対BDD。このテストツール対あのテストツール。テストビフォー対テストアフター対これは動くから俺を信じろ。ある時期から、こうした詳細に関する議論には飽きてしまった。もっと原則について議論したい。 詳細に関する議論はなかなか結論に至らずに、話が行ったり来たりする。チョコレート対バニラ。チョコレート。バニラ。チョコレート。バニラ。 詳細の議論に負けを認めさせられるようなことがあっても、その譲歩は絶対的なものではない。私の状況がチョコレートを勧めているのに、私にバニラを食べさせてくれと言えるだろうか？ これでは埒が明かない。 原則一方、原則は議論を生み出す基盤になる。原則には賛成しても状況が違っているのなら、答えは違ってくるかもしれないが、そこで論争になることはない。原則が、異なる状況における異なる答えを生み出したのである。 詳細で論争するよりも、原則で論争したほうが生産
テストを書きたくない話 / I don't want to write tests
2019/10/11に行われた「「テスト」の話を聞いてみようの会」での登壇資料です
XP祭り2019 B-6 アジャイルソフトウェア開発への統計的品質管理の応用
English Version： https://www.slideshare.net/sakataakinori/xp-fes-2019-b6-application-of-statistical-quality-control-to-agile-software-development XP祭り2019 B-6 「アジャイルソフトウェア開発への統計的品質管理の応用」の資料です。 On 2019年8月20日, in XP祭り2019, XP祭り2019セッション 【セッション情報】 セッションID：B-6 時間：14:45～15:15（30分） 会場：B（1F 102室・後） タイプ：講演 【セッション内容】 アジャイル開発のマネージメントやチーム運営のお手伝いをしていく中で、ウォータフォールで使われている品質メトリクスを利用しようとしているプロジェクトを見かけることがあります。 ウォー
ツールは解決策ではない | POSTD
最近、『The Atlantic』に掲載された非常に重苦しい 記事 「The Coming Software Apocalypse」（きたるソフトウェア大惨事）を読み終えました。同記事は最初のうちは、人に傷害を与えたり、人の命を奪ったりした恐ろしいソフトウェアバグについて述べており、いい内容です。しかし、途中から急に残念な展開になっているのです。 同記事の著者はソフトウェア業界の多くの思想的リーダーにインタビューをしましたが、 Light Table 、 モデル駆動工学 、 TLA+ といった新しい技術を生み出したリーダーだけを選んでいます。 私はこうしたツールに何ら反対しているわけではありません。Light Tableプロジェクトに資金提供さえしました。優れたソフトウェアツールは優れたソフトウェアを書きやすくすると思います。しかし、ツールは「大惨事」に対する解決策ではありません。 著者は
Business velocity and customer satisfaction boosted as banks move to cloud native
Insights linkInsightsExplore our latest thought leadership, ideas, and insights on the issues that are shaping the future of business and society. Learn more Reshape our future with Generative AI Leading sustainability The future of technology Marketing for customer experience Our research library Expert perspectives Industries linkIndustriesChoose a partner with intimate knowledge of your industr
開発現場に学ぶ、円滑なコードレビューに必要な8つの手法 ～手段から準備、実施時期まで徹底解説～｜ハイクラス転職・求人情報サイト AMBI（アンビ）
開発現場に学ぶ、円滑なコードレビューに必要な8つの手法 ～手段から準備、実施時期まで徹底解説～ コードレビューによって解決される問題とは？そして、実際にチームでコードレビューを実施する上で気をつけるべきこととは？ソニックガーデンの取締役プログラマー西見公宏さんが、コードレビューのポイントを、実践に基づき解説します。 ITを活用して事業の課題を解決するサービス「納品のない受託開発」を提供する会社、ソニックガーデンの西見公宏（にしみ・まさひろ／@mah_lab）です。お客様の「バーチャルCTO」として、サービスの企画からシステムの開発・運用まで、日夜幅広く関わらせていただいております。 皆さんは普段、ソースコードをどのくらい読んでいるでしょうか？ 普段からソフトウェア開発をしている人であれば、何か問題が起こったときの原因調査のために他の人が書いたコードを読んだり、はたまた自分の書いたコードを読
『希薄化したTDD、プロダクトの成長のために必要なものは？〜『健全なビジネスの継続的成長のためには健全なコードが必要だ』対談 （６）』へのコメント
テクノロジー 希薄化したTDD、プロダクトの成長のために必要なものは？〜『健全なビジネスの継続的成長のためには健全なコードが必要だ』対談 （６）
希薄化したTDD、プロダクトの成長のために必要なものは？〜『健全なビジネスの継続的成長のためには健全なコードが必要だ』対談 （６）
テスト書くのが当たり前、だけど・・・和田：次に意味の希薄化ですね。『Test-Driven Development by Example』の出版から15年経ち、テストコードを書く人はすごく増えました。15年前は啓蒙期で、テストコードを書きましょう、テストコードの書き方はこういう感じですというのを頑張って啓蒙する必要があった。 でも、例えば今の若手プログラマーは普通にテストコードを書く。なぜなら既存システムにはテストコードが書かれているから、開発の継続、不具合の修正とか機能追加を行う際にテストコードを書くのが普通だし、テストコードが無いとレビューは通らないしみたいな話になって、テストコードがあるという生活は普通のものになっている。そうすると、なぜテストコード書くのかとか、本来こういうテストコードを書きたかったんだけどとか、こういうテストを書くべきなんだけどみたいな議論はだいぶ土俵から外れてし
xUTP Magazine - xUnitester Hotlinks: 第一回 和田卓人さん(下)
xUnitester Hotlinks は、毎号、著名な xUnitester にインタビューを行っていこう、という企画です。 栄えある第一回のインタビューは、日本の TDD 伝道師、和田卓人さんにお願いしました。 こちらは後編となります。前編はこちら 和田卓人（わだたくと） タワーズ・クエスト株式会社取締役社長、プログラマ、テスト駆動開発者。 学生時代にソフトウェア工学を学び、オブジェクト指向分析/設計に傾倒する。その後様々な縁に導かれソフトウェアパターンやXP（eXtreme Programming）を実践する人たちと出会い、後のテスト駆動開発の誕生を知る。テスト駆動開発に「完璧主義の呪い（完璧な設計を得るまではコードを書けないし良いシステムも出来ないという強迫観念）」を解いてもらってからは、文章を書いたり、講演を行ったり、ハンズオンイベントを開催するなどして、テスト駆動開発を広めよう
実践テスト駆動開発(GOOS)読んだ - Qiita
実践テスト駆動開発を読んだ（和智さんいい仕事、ありがとう！）。 タイトル(GOOS = "Growing Object-Oriented Software, Guided By Tests")に、「テスト（TDD）」と「オブジェクト指向（Object-Oriented）」と「育てる（Growing）」が入っていて、ずっと読まなきゃと思っていた。出たときに角谷さんに「これは！」、と薦められたのに、機会を失っていたけど、最近、astahの開発でテストに悩みがあって読んでみた。 外から攻めるか、内からか テストを書いてプロダクトコードを育てていくという話なのだが、内側のテスト（ユニットテスト）と外側のシステムテスト（受け入れテスト、システムテスト、エンド・トゥ・エンド(E2E)テスト)をどっちを先に書くべきかいつも悩む。外側のテストを書いて、内側に進んでいくのか、内側から組み上げるか。設計の方向
マニアが潰したテスト駆動開発〜『健全なビジネスの継続的成長のためには健全なコードが必要だ』対談 （５）
昨年１２月に行われた和田卓人氏と『時を超えたプログラミングの道』編集長／『スクラム実践入門』著者の家永英治氏の『健全なビジネスの継続的成長のためには健全なコードが必要だ』対談の記事第5弾をお届けします。 対談のこれまでの記事は以下になります。
JaSST'18 Tokyo 基調講演「Advances in Continuous Integration Testing at Google」 質疑応答 #JaSST
broccoli @nihonbuson ハードウェアの自動化に良いアイディアはあるか？ どれだけデジタル化が進んでいるかによる アルゴリズムのみをテストするならば可能だと思う #JaSST 2018-03-07 10:52:44 broccoli @nihonbuson トランジションの話の前提として、どれぐらいのカバレッジが達成できているのか？ 別のシステムを設けて、カバレッジを測定している。 コードカバレッジはチームに寄って違う。 80%以上のチームもあれば計っていないチームもある 収入が高いチームはカバレッジが高い。成熟度によって変わる #JaSST 2018-03-07 10:54:23 broccoli @nihonbuson テストができている段階の話をしていたが、どういうテストを作るというような指針はあるか？ 一般的なルールは、コードレビュー時に同時にテストコードをサブミッ
GoogleのJohn Micco氏によるFlakyなテストとその判別方法の解説 #JaSST - ブロッコリーのブログ
はじめに FLAKYの内容が今はっきりした！#JaSST— broccoli (@nihonbuson) 2018年3月8日 と書い（てしまっ）たので、JaSST'18 Tokyoに参加した私なりのFlakyの解釈を書きます。 JaSST'18 Tokyoについては以下のページを参照してください。 JaSSTソフトウェアテストシンポジウム-JaSST'18 Tokyo お知らせ この記事の内容を4/11に発表しました！ nihonbuson.hatenadiary.jp 発表スライドはこちら speakerdeck.com 目次 はじめに お知らせ 目次 Micco氏のお話 ICSTでの話 基調講演「Advances in Continuous Integration Testing at Google」 講演資料 テスト文化について (3ページ付近) 回帰テスト (4ページ付近) Mil
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
JaSST' Tokai 18 - Agileとテスト自動化導入の勘所
外部に依存したコードもテストで駆動する / Test-Driven Architecture - AWS Dev Day Tokyo 2018 - Speaker Deck
Difference between System testing and Acceptance Testing
安全かつ高速に進めるマイクロサービス化 / railsdm2018 - Speaker Deck
