並び順

ブックマーク数

期間指定

  • から
  • まで

161 - 200 件 / 3365件

新着順 人気順

単体テストの検索結果161 - 200 件 / 3365件

  • 【魚拓】みずほ銀行の炎上プロジェクトに支援に行ってきた話|問題編 - ここもちろぐ

    URL: http://www.cocoamocchi.com/entry/project-bank-problem 取得日時: 2018年6月4日 18:18 削除理由: 個人情報削除済み 手続日時: 2018年6月10日 23:46

      【魚拓】みずほ銀行の炎上プロジェクトに支援に行ってきた話|問題編 - ここもちろぐ
    • テストしやすいGoコードのデザイン

      テストしやすいGoコードのデザイン golang.tokyo #2 12 December 2016 Taichi Nakashima 言いたいこと 明示的であれ! 2 whoami @deeeet / @tcnksm (GitHub) http://deeeet.com A PaaS Dev&Ops (Using go for CLI tool, API, Batch jobs) 3 OSS Tools gcli - The easy way to build Golang command-line application ghr - Create Github Release and upload artifacts in parallel Packages go-httpstat - Go package for tracing golang HTTP request latency

      • 組織にテストを書く文化を根付かせる戦略と戦術 / Strategy and Tactics of Building Automated Testing Culture into Organization

        2017/12/19 Tech Night @ Shiodome # 6 https://techsio.connpass.com/event/72585/

          組織にテストを書く文化を根付かせる戦略と戦術 / Strategy and Tactics of Building Automated Testing Culture into Organization
        • エキスパート Python プログラミング — エキスパート Python プログラミング v0.9 documentation

          1章: 始めよう¶ Pythonのインストール Pythonの実装系 Jython IronPython PyPy その他の実装 Linux へのインストール パッケージインストール ソースコンパイル Windows へのインストール Python のインストール MinGW のインストール MSYS のインストール Mac OS X へのインストール パッケージインストール ソースコンパイル Python プロンプト インタラクティブプロンプトのカスタマイズ iPython: より良いプロンプト setuptools のインストール 動作原理を理解する EasyInstallを使ったsetuptoolsのインストール distutilsにMinGWのフックを入れる 作業環境 エディターと補助ツールを使う コードエディター Vimのインストールと設定 その他のエディタを使う その他のバイナ

          • フロントエンドのテストは皆のためのもの | POSTD

            テストとは人によって反応が分かれるものの1つであり、大喜びする人もいれば、見ないようにして去ろうとする人もいます。あなたがどちらの側であるにせよ、ここではフロントエンドのテストは皆のためのものであるということを説明します。実際、テストには多くの種類があり、それがテストに対して初めに恐れや混乱を感じる一因なのかもしれません。 この記事では、特に有名で広く利用されている種類のテストを扱います。なかには目新しいものはないと感じる読者の方もいらっしゃるかもしれませんが、少なくとも復習にはなるでしょう。どちらにせよ、筆者の目標は、この記事を通じて世の中のさまざまな種類のテストについて理解を深めてもらうことです。ここではユニットテスト、統合テスト、アクセシビリティテスト、ビジュアルリグレッションテストなどを一緒に見ていきます。 さらに、Mocha、Jest、Puppeteer、Cypressなど、各種

              フロントエンドのテストは皆のためのもの | POSTD
            • ソースコード以外もとにかくテストする。もしくはカバレッジだけではダメだという話 | おそらくはそれさえも平凡な日々

              あなたはプロジェクトのソースコードに対して適切にCIを回しているかもしれません。定期的にコードカバレッジの測定も行い、90%以上もしくは100%の数字を出しているかもしれません。 しかし果たしてそれで十分でしょうか?もしくはコードカバレッジだけにとらわれすぎていないでしょうか? 監視とは(システムに対する)継続的なテストである、というのは筆者の尊敬する奥一穂氏の言葉ですが、その逆もしかりで 「テストとはプロジェクトに対する継続的な監視である」 ということも言えます。 その観点に立ってみると、プロジェクトのソースコード以外にもテストが必要なものがたくさんあることに気づくでしょう。以下に実際に筆者が自分のプロジェクトの中でソースコード以外にテストを書き、CIを回していたものを挙げてみます。 アプリケーション設定ファイルのテスト 開発中に本番用の設定ファイルを使うことはないため、本番用の設定ファ

                ソースコード以外もとにかくテストする。もしくはカバレッジだけではダメだという話 | おそらくはそれさえも平凡な日々
              • TechCrunch | Startup and Technology News

                While all of Wesley Chan’s success has been well-documented over the years, his personal journey…not so much. Chan spoke to TechCrunch about the ways his life impacts how he invests in startups.

                  TechCrunch | Startup and Technology News
                • 開発とテストの融合こそゴール。続、グーグルはあれほど多くのソフトウェアのテストをどのように行っているのか?

                  開発とテストの融合こそゴール。続、グーグルはあれほど多くのソフトウェアのテストをどのように行っているのか? グーグルでTest Engineering Directorを務めるJames A Whittaker氏が書いたエントリを紹介した先日の記事「グーグルはあれほど多くのソフトウェアのテストをどのように行っているのか?」が非常に好評で、「続きがあれば読みたい」というコメントをいただいていました。 Whittaker氏がそのエントリの続き「How Google Tests Software - Part Threeを公開していますので、ご要望に応えて紹介することにしましょう。 品質は開発の問題であってテストの問題ではない 品質とはどのように実現するものなのか? という問いに対して、Whittaker氏は次のように書いています。 The simple solution to this con

                    開発とテストの融合こそゴール。続、グーグルはあれほど多くのソフトウェアのテストをどのように行っているのか?
                  • 初めての自動テスト

                    Webシステムの自動テストを始めたい方を対象に、自動テストの考え方やフレームワークを解説する書籍です。テストのピラミッドやユーザーインターフェイステストの概念など、基礎的な事柄から、レガシーシステムへのUIテストの追加、RESTfulなWebサービスのテスト、ブラウザ上のJavaScriptの挙動をユニットテストでテストする方法など、実践的な事柄までを豊富なイラストとサンプルを使って分かりやすく解説します。さらにテストファーストやモックの活用法、テスターに向けた自動テストのためのプログラミング基礎知識なども詳述。自動テストを書くためのノウハウを網羅した本書は、自動テストをマスターしたいエンジニア必携の一冊です。 正誤表 ここで紹介する正誤表には、書籍発行後に気づいた誤植や更新された情報を掲載しています。以下のリストに記載の年月は、正誤表を作成し、増刷書籍を印刷した月です。お手持ちの書籍では

                      初めての自動テスト
                    • テスト、正常系から書くか異常系から書くか - hitode909の日記

                      今週は同僚と毎日長時間ペアプロしていた。 おもしろかったのが、同僚のテストの書き進め方で、一番複雑な正常系のテストをちゃんと書いてから、その複雑なテストをもとに、いろんな条件を削っていって異常系のテストを作っていく、というところ。 僕は逆で、入力が空なら何も起きない、とか、一番簡単な異常系のテストを書いて、そこだけ通るのを確認して、よしよし、と進めていって、メソッド本来の動きは最後に確認して終わる。 変な進め方だな〜(主観)と思って眺めていたけど、たしかに正常系のテストが通っていれば、あとはバリデーションまわりのチェックとか、例外となる場合のチェックをすれば終わりで、異常系のテストがすごい速さで書かれていておもしろかった。 …という話をしたら、チームメンバーたちは正常系のテストから書きはじめるという人が多くて、正しくことを確認してから、1個ずつ前提となる条件を外してみて試す、と聞いて、同値

                        テスト、正常系から書くか異常系から書くか - hitode909の日記
                      • マイクロソフト、Visual Studio 2017正式リリース。コードを書きながら自動的にユニットテストを実行してくれるライブユニットテスティングなど

                        Visual Studio 2017はさまざまなプログラミング言語やプラットフォームに対応。C#や.NET Frameworkを用いたWindowsアプリケーションだけでなく、C++でLinux対応のアプリケーションを開発することも、TypeScriptでWebアプリケーションを開発することも、クラウドアプリケーションやモバイルアプリケーションの開発も可能です。 Visual Studio 2017ではインストールの時間を大幅に短縮。いままで2時間ほどかかっていたインストールを10分程度に短縮。 また必要な機能のみを必要なときに読み込む構造にすることで、起動時間も約半分になり、従来より軽快に動作すると説明されています。 開発者にとって注目すべき新機能のひとつは、C#かVisual Basicでコードを書いている場合、バックグラウンドで自動的にユニットテストを実行してくれる「ライブユニットテ

                          マイクロソフト、Visual Studio 2017正式リリース。コードを書きながら自動的にユニットテストを実行してくれるライブユニットテスティングなど
                        • Visual Studio Code は JavaScript 開発が超絶便利になる可能性を秘めている!

                          Visual Studio Code は JavaScript 開発が超絶便利になる可能性を秘めている! クロスプラットフォームでオープンソースな IDE 環境、Visual Studio Code が公開されたので試してみた。 拡張を入れなくても、デフォルトで JavaScript の「自動 Lint」「Grunt、Gulp 連携」「デバッグ」が動いた。なんだかすごく便利そうな予感。 Windows 環境で起動してみたらこんな画面だった。 なんか黒いが、色は好みにカスタマイズできるし、プリセットからも選べる。 フォルダーを開くことから始まる Visual Studio Code にはプロジェクトの概念はない。 [File] > [Open Folder] からフォルダーを開けばよい。 ためしに、過去に作った Node.js 製の livereloadx のフォルダーを開いてみた。 左側に

                            Visual Studio Code は JavaScript 開発が超絶便利になる可能性を秘めている!
                          • GitHub - mixi-inc/AndroidTraining: Training course repository for android app development

                            You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert

                              GitHub - mixi-inc/AndroidTraining: Training course repository for android app development
                            • TddAntiPatterns - TDD のアンチパターン

                              TddAntiPatterns - TDD のアンチパターン 目次 この文書について TDD のアンチパターン TDD アンチパターン・カタログ 嘘つき。 (The Liar) セットアップ過多 (Excessive Setup) 巨人 (The Giant) モック酔い (The Mockery) 検査官 (The Inspector) 太っ腹な残り物 (Generous Leftovers) 地元の英雄 (Local Hero) 小姑 (The Nitpicker) 秘密のキャッチ (The Secret Catcher) ペテン師 (The Dodger) 大声 (The Loudmouth) はらぺこキャッチ (The Greedy Catcher) 序列屋 (The Sequencer) 隠れ依存 (Hidden Dependency) 点呼 (The Enumerator)

                              • 「アジャイルサムライ」の著者が語る、技術志向の企業が世界をどう見ているのか? そしてソフトウェアテスト自動化を進化させる方法について(前編)。JaSST'22 Tokyo基調講演

                                「アジャイルサムライ」の著者が語る、技術志向の企業が世界をどう見ているのか? そしてソフトウェアテスト自動化を進化させる方法について(前編)。JaSST'22 Tokyo基調講演 Jonathan Rasmusson(ジョナサン・ラスムッソン)氏はアジャイル開発における著名人の一人であり、さまざまな先進的ソフトウェア企業において開発やテストに携わってきました。 日本ではアジャイル開発の入門書として話題となった書籍「アジャイルサムライ」(オーム社,2011)や「初めての自動テスト」(オライリー,2021)、「ユニコーン企業のひみつ」(オライリー,2017)の著者としても有名です。 そのラスムッソン氏が2022年3月10日と11日の2日間、ソフトウェアのテストに関わる国内最大のイベント「ソフトウェアテストシンポジウム 2022 東京」(JaSST'22 Tokyo)の基調講演に登壇しました。

                                  「アジャイルサムライ」の著者が語る、技術志向の企業が世界をどう見ているのか? そしてソフトウェアテスト自動化を進化させる方法について(前編)。JaSST'22 Tokyo基調講演
                                • 2011年のJavaScript ─ウェブアプリ全盛の時代へ | gihyo.jp

                                  あけましておめでとうございます。昨年に引き続き、今年もJavaScriptの近い未来についてちょっとだけお話させて頂きます。 最初に昨年の予想を見返しておきましょう。昨年は次の3つを2010年の鍵として取り上げました。 ウェブ標準 ブラウザ拡張 サーバーサイドJavaScript この3つを軸に2010年を振り返ってみます。 2010年のJavaScript界隈でのニュース ウェブ標準 2010年最初のビッグニュースはなんといってもIE 9のPlatform Preview版の登場でした。これまでの独自実装路線から一転して(正確にはIE 8の時点でJSONやWeb Storageのサポートなど、その徴候はあったのですが⁠)⁠、HTML5などのウェブ標準のサポートを進めることを表明しました。そして実際に8週おきにPlatform Preview版をアップデートして、ECMAScript5・S

                                    2011年のJavaScript ─ウェブアプリ全盛の時代へ | gihyo.jp
                                  • ChatGPT、何が問題か 元グーグル社員「非常に無責任で無謀」:朝日新聞デジタル

                                    ","naka5":"<!-- BFF501 PC記事下(中⑤企画)パーツ=1541 --><!--株価検索 中⑤企画-->","naka6":"<!-- BFF486 PC記事下(中⑥デジ編)パーツ=8826 --><!-- /news/esi/ichikiji/c6/default.htm -->","naka6Sp":"<!-- BFF3053 SP記事下(中⑥デジ編)パーツ=8826 -->","adcreative72":"<!-- BFF920 広告枠)ADCREATIVE-72 こんな特集も -->\n<!-- Ad BGN -->\n<!-- dfptag PC誘導枠5行 ★ここから -->\n<div class=\"p_infeed_list_wrapper\" id=\"p_infeed_list1\">\n <div class=\"p_infeed_list\">

                                      ChatGPT、何が問題か 元グーグル社員「非常に無責任で無謀」:朝日新聞デジタル
                                    • 最近やってるRailsプロジェクトのテスト方法 - #詰んでる日記

                                      Railsエンジニアになってから1年半くらいが経ち、社内のRailsのプロジェクトを全部で5つくらい触って、今やってるAbilie*1でようやく人並みにテストを書いてる気がしてきたので、現時点でやってるテストの方法をまとめておく。 テストのルール的なの rspecでは必ずモデルのテストは書くようにしてる。ヘルパーも大体書いてるけど、コントローラやルーティングのテストはあまり書いてない。 というのも、コントローラーのコードを極力短くしてモデルを太らせているのでコントローラのテストはあんまり意味が無い気がしていて、その代わりにCapybaraでテストを書いておけば十分なんじゃないかなと思ってきたから。Capybaraは書いてるので、そういう意味では書いてるとも言える。 社内の管理者だけが使える管理画面も作ってるけど、そっちはテストあんまり書いてない。ここは動かなくなっても一般ユーザーには影響が

                                        最近やってるRailsプロジェクトのテスト方法 - #詰んでる日記
                                      • 「ほとんどのユニットテストが役に立たない理由」を読んで | POSTD

                                        数ヶ月前、私はJames O Coplienの ほとんどのユニットテストが役に立たない理由 という記事に出会いました。Jamesはほとんどのユニットテストは無意味であると考えていて、タイトルは内容をそのまま正確に表しています。彼は 追加記事 で議論をさらに展開しています。私は彼の議論に大変興味をそそられました。というのは、私はユニットテストから多くの利益を得ているからです。私たちはどうしてこのような異なる見解を持つに至ったのでしょうか? 私が何かを見逃したのでしょうか? 結局のところ私は彼の見解に賛成できませんでした。以下は彼の記事に対する私の意見です。 ユニットテストが必要な場合 私の経験では、ユニットテストはアルゴリズムロジックに対して行う時に最も有益です。結合度の高いコードについてはその性質から特に有益ではありません。結合度が高いコードはユニットテストのために多くのモックオブジェクト

                                          「ほとんどのユニットテストが役に立たない理由」を読んで | POSTD
                                        • Technical Note TN2267: Video Decode Acceleration Framework Reference

                                          • AWS Lambda(Python) の開発環境・テスト・デプロイ・CI 考察 | DevelopersIO

                                            作るもの ヒーローを管理する Lambda Function を書きます。ヒーロー情報は DynamoDB の ヒーローテーブルに格納するものとします。リポジトリは以下。 * Python Lambda SAM + SAM Local Project コーディング作業 すべてはコードを書くところから始めます。いきなりプロジェクトルートにファイルを置いて書き始めるのも良いですが、後々テストやデプロイも行うことになるので少し整理してみます。以下のようにしました。 . ├── buildspec.yml ├── deploy.sh ├── docker-compose.yml ├── environments │   ├── common.sh │   └── sam-local.json ├── integration_test.sh ├── requirements.txt ├── src

                                              AWS Lambda(Python) の開発環境・テスト・デプロイ・CI 考察 | DevelopersIO
                                            • マイクロソフトの責任者が語る「われわれはどのようにソフトウェアをテストしているか?」 JaSST'12 Tokyo

                                              マイクロソフトの責任者が語る「われわれはどのようにソフトウェアをテストしているか?」 JaSST'12 Tokyo ソフトウェアのテストに関わるエンジニアが集まる国内最大のイベント「ソフトウェアテストシンポジウム JaSST'12 Tokyo」が1月25日、26日の2日間、都内で開催されました。 10周年を迎えた今回のイベントの基調講演を行ったのが、開発しているソフトウェアの規模、分野、種類において世界最大の企業、マイクロソフトのプリンシパル テストリードのBj Rollison氏。 「How We Test At Microsoft(マイクロソフトでどのようにテストをしているのか?)」という題で、同社がどのようなソフトウェアテストを行っているのかを中心に講演を行いました。講演の内容をダイジェストで紹介しましょう。 開発者とテスターはほぼ同数 マイクロソフト プリンシパル テストリードのB

                                                マイクロソフトの責任者が語る「われわれはどのようにソフトウェアをテストしているか?」 JaSST'12 Tokyo
                                              • PHP版レガシーコード改善に役立つ新パターン #wewlc_jp

                                                9/27に行われたレガシーコード改善勉強会で発表された資料です。 http://passmarket.yahoo.co.jp/event/show/detail/01pitgwzj67m.htmlRead less

                                                  PHP版レガシーコード改善に役立つ新パターン #wewlc_jp
                                                • いまからでも間に合う開発者テスト - mixi engineer blog

                                                  はじめまして。開発部じゃない加藤和良です。 最近、mixi では Buildbot をつかった継続的インテグレーションをはじめています。安定版の mixi のソースコードにコミットすると Buildbot がそれを検知し、自動的にテストが走るようになりました。 ここでの「テスト」は Test::Simple や prove(1) をつかった、Perl でかかれた開発者テストを指しています。mixi の開発者テストをとりまく環境は、ここ数年でかなり改善されました。今回はその歩みをふりかえりながら、テストの無いコードベースをどこからどうやって変えていったかという話をしたいと思います。 開発環境 はじめに、前提となる mixi の開発環境について説明します。mixi では複数人の開発者がひとつのマシンで作業を行います。それぞれの開発者は、あらかじめ割り当てられたポートで Apache を起動し、

                                                    いまからでも間に合う開発者テスト - mixi engineer blog
                                                  • テスト書きすぎ問題 - hitode909の日記

                                                    テスト書きすぎるとよくないって言ってる人がいた.DHHっていう人.作業時間の1/3以上テストしてたらおかしいとか,ActiveRecordのバリデーションなど,Railsの機能はテストしない,とか. Signals vs. Noiseの去年のエントリに、テストをどれくらい書くべきかということについてDHHが指針を示していたものがあったので... - Sooey 偉い人が言ってるからという理由で,テスト手抜き派の人に良い材料を与えてしまった.僕は意見ちがって,作業時間半分以上はテスト書いたりしてる. テストたくさん書くと,最初に書くときのコストは増える.けど,あとから読む時や,変更したい時には,読むだけだし,書くのも差分だけで良い.コード本体を理解できれば,要らないテスト捨てるのは,落ちたのを消すだけだから簡単.あとで見て,テスト足りないと分かったときに,明文化されてない仕様からテストを補う

                                                      テスト書きすぎ問題 - hitode909の日記
                                                    • TDD Anti-patterns catalogue at Stack Overflow を簡単に訳してみた - joker1007’s diary

                                                      Stack OverflowのTDD Anti-patterns catalogueというスレがとても面白かったので訳してみた。 Stack Overflowのvoting機能でアンチパターンへの投票を行っている感じ。 上から投票の多い順になっている。 得票数はこの記事執筆時点(2013.7.9)のもの。 SQLアンチパターンっぽく、パターン名はそのまま片仮名にしてみた。 また、内容がかなり被っているとか、状況がかなりレアじゃないかと思うものは、一部省略しました。 (ブコメで訳間違ってるよ、って教えてもらったので、一部修正しました 2013.7.10) フリーライド (テストのただ乗り) 50pt 新しいテストケースを書くのではなく、他の機能のテストに新しいアサーションを追加して既存のテストケースに乗っかる。 セカンドクラス シティズン (二等市民) 47pt プロダクションコードのように

                                                        TDD Anti-patterns catalogue at Stack Overflow を簡単に訳してみた - joker1007’s diary
                                                      • テストコードを書く文化を根付かせたい─和田卓人|【Tech総研】

                                                        日本におけるテスト駆動開発(TDD)のスペシャリストとして知られる和田卓人氏。講演活動やハンズオンイベントを通してテストの重要性を語り続けている。その深奥にあるプログラムの哲学とは── 父親がデータベース設計を得意にするソフトウェア・エンジニアで、受託開発の会社を経営していました。私は大学在学中からその仕事を手伝っていて、その延長で大学を出るとその会社の一員になりました。 そのころのことで一番印象に残っているのは、電子政府関連の公共システム開発に関わる大規模プロジェクトへの参加です。複数のSIerやソフトハウスが関わり、要件定義に時間をかけ、膨大な設計文書をつくっては、何千人というエンジニアを投入する、典型的な大規模システム開発です。私はそこにSEの一員として参加することになりました。 ただ、私は初日から生意気にも「Excelで設計書を書き続けるために来たのではありません」と嘆願して、基盤

                                                        • Go言語で API サーバーを開発する | カメリオ開発者ブログ

                                                          こんにちは!白ヤギの開発者、森本です。 白ヤギではいま API サーバーを Go 言語で開発しています。 皆さんも Go の話題をよく見聞きするようになっていると思います。今回は白ヤギの業務でどんな風に Go を使って開発しているかの一端を紹介します。 余談ですが、先日、大学の先生とお話ししたときにこんな話を伺いました。その先生は学生にプログラミングを教えているそうですが、何割かの学生は及第点に届かないそうです。しかし、そういった学生がプログラミングの素養がないかというとそういう訳ではなく、プログラミングを学ぶ上でその学生にとって何が理解を促すのかが違うだけなのだと仰っていました。教える側として全ての学生が習得できるプログラミング教育というのを見つけられていないのが悔しいといった話をされていました。 何かを学ぶというのを一般論では語るのは難しいということかもしれません。そのため、私はこうい

                                                            Go言語で API サーバーを開発する | カメリオ開発者ブログ
                                                          • かっこ悪くて面倒でもテストコードを書こう - 今川館

                                                            Python | 10:08わたしはプログラマーではありませんが、いくつかの仕事でテストコードを見たり書いたりすることがあったので、その過程で思ったことをメモとして残しておきます。コーディングとテストを分けて工数を言う癖をやめようどっちもコードを書くのだから分けて考える必要はないテストコードの重要性は理解しているけど、工数も厳しいし客がテストコードを書くことに工数を割くことを認めてくれない。ありがちな話ですが、それがテストを書かないことの根拠であるならば少し考え直しましょう。コーディングとテストを異なる工程と考えるのをやめてしまえばそんなことに悩む必要はなくなります。つまり、「テストを書きながらコーディングする」のです。だいたい、普段プログラムを書いているときだって手元で動かしながらものを作っているでしょう。それと同じことをプログラムを書いてやればいいだけです。客がテストを書かせてくれない

                                                            • 「最強」のチームを「造る」技術基盤

                                                              「最強」のチームを「造る」技術基盤 Presentation Transcript 「最強」のチームを 「造る」技術基盤 Nov/09/2013 Hiroyuki Ito IT Department, Rakuten, Inc. http://www.rakuten.co.jp/ Hiroyuki Ito (伊藤 宏幸、The Hiro) 情報技術部 プロセス・品質課 テスト駆動開発グループ @hageyahhoo 2 アジャイルコーチとして、 開発現場を日々サポートさせていただいています。 3 造る = 栽培する・耕す 4 CI/CD TDD ATDD この3つを軸にした チーム造りについてお話します。 5 Agenda 1. チーム造りの背景 2. 1st Stage : CI/CD 3. 2nd Stage : TDD for Android 4. 3rd Stage : ATDD

                                                              • TDD is dead. Long live testing. (DHH)

                                                                By David Heinemeier Hansson on April 23, 2014 Test-first fundamentalism is like abstinence-only sex ed: An unrealistic, ineffective morality campaign for self-loathing and shaming. It didn't start out like that. When I first discovered TDD, it was like a courteous invitation to a better world of writing software. A mind hack to get you going with the practice of testing where no testing had happen

                                                                • ふつうのユニットテストのための7つのルール - ブログなんだよもん

                                                                  最近、久しぶりにコードレビューをすることが増えたのですが、UnitTestのコードを見るとヒドイ部分が多く残念な気持ちになることもあります。 原因のひとつとして、プロダクトコードと違いテストの書き方をあまり書き方を明文化してなかったのが悪かったなと思い、とりあえず明文化してみました。 今回は、命名規則とかそのレベルまではいかず「ユニットテストかくあるべし」ってところまでをまとめます。正直、これ守ってくれたらあとは好みの世界もあるしね。 追記: テクニカルな部分も最低限ですがQiitaに記載しました。 qiita.com 追記: もうちょっと大上段の規約に関してもまとめてみました。 koduki.hatenablog.com 前提 ここではユニットテストを関数レベルのテストをJUnitのような自動テストツールで取り扱う場合に限定します。 また、Mavenでビルド時は常にテストを回すことを想定

                                                                    ふつうのユニットテストのための7つのルール - ブログなんだよもん
                                                                  • こんなに使える!今どきのAPIドキュメンテーションツール

                                                                    2017/05/26のDB比較セミナーで使用した資料です。 NoSQLであるRedisについて説明しています。

                                                                      こんなに使える!今どきのAPIドキュメンテーションツール
                                                                    • www.phptherightway.com

                                                                      Welcome There’s a lot of outdated information on the Web that leads new PHP users astray, propagating bad practices and insecure code. PHP: The Right Way is an easy-to-read, quick reference for PHP popular coding standards, links to authoritative tutorials around the Web, and what the contributors consider to be best practices at present. There is no canonical way to use PHP. This website aims to

                                                                      • 保守しやすく変化に強いソフトウェアを支える柱 自動テストとテスト駆動開発、その全体像 ~Software Design 2022年3月号「そろそろはじめるテスト駆動開発」より | gihyo.jp

                                                                        保守しやすく変化に強いソフトウェアを支える柱 自動テストとテスト駆動開発⁠⁠、その全体像 ~Software Design 2022年3月号「そろそろはじめるテスト駆動開発」より 今回、Software Design 2022年3月号 第2特集「そろそろはじめるテスト駆動開発 JavaScriptでテストファーストに挑戦」の第1章「保守しやすく変化に強いソフトウェアを支える柱 自動テストとテスト駆動開発、その全体像」を本サイトに掲載します。第2章以降については、本誌『Software Design 2022年3月号』電子版(Gihyo Digital Publishing、Amazon Kindle)をご購読いただければ幸いです。 第1章では、混同されることの多い自動テスト関係の概念を、自動テスト、テストファースト、テスト駆動開発の3つの段階に分け、それぞれの効果や注意点を説明します。ソフ

                                                                          保守しやすく変化に強いソフトウェアを支える柱 自動テストとテスト駆動開発、その全体像 ~Software Design 2022年3月号「そろそろはじめるテスト駆動開発」より | gihyo.jp
                                                                        • Browserling – Online cross-browser testing

                                                                          Not just screenshots! You can interact with the browsers live as if they were installed on your computer.

                                                                            Browserling – Online cross-browser testing
                                                                          • テストコード導入奮闘記~私はこうやってプロジェクトにテストコードを導入しました~ - Qiita

                                                                            導入 どうやら新卒2年目社員のAさんが上司のZさんにプロジェクトにおいてテストコード導入を打診してるようです。少し内容を見てみましょうか。 Aさん(新卒2年目社員)「最近テスト自動化やテストコード、TDDなどの単語をよく聞きます。うちはテストコード書いてないですし、実装後の簡単な動作確認、最終の結合テストしかしていません。開発体験と品質を上げるために、テストコードを導入したいです。」 Zさん(上司)「そうは言うがね、君。今のうちの状況を見てごらんよ。みんな複数のプロジェクトに関わっていて、常に多忙。残業時間もぎりぎりで何とかプロジェクトが回っている状態だよ。そんなみんなにさらに作業を増やすようなことを提案するというのかね?しかも、テストコードはお客様からしたら作っても作らなくても関係ない、いわば直接利益に関係ないような作業じゃないか。もちろん、世の中で認知されているということは知ってるよ?

                                                                              テストコード導入奮闘記~私はこうやってプロジェクトにテストコードを導入しました~ - Qiita
                                                                            • Selenium IDEを使って、ChromeやIE上でテストスクリプトを実行する方法 | MagicPod Tech Blog | MagicPod: AIテスト自動化プラットフォーム

                                                                              Selenium IDEは、ブラウザ操作を記録してSeleniumのスクリプトを生成できるFirefoxプラグインで、プログラムを書かなくてもSeleniumのスクリプトが作成できることから、多くの人に利用されています。 記録したスクリプトの再生をSelenium IDEで行うこともできるのですが、Firefoxプラグインということもあり、これまで実行はFirefoxでしか行うことができませんでした。 しかし、2013年4月26日にリリースされたSelenium IDE 2.0を使えば、Selenium IDEからChromeやInternet Explorerなど他のブラウザ上でのテストスクリプト実行を行えるようになりました。 今回は、SeleniumのコミッターであるSamit Badle 氏のブログ記事 "WebDriver Playback in Selenium IDE is H

                                                                                Selenium IDEを使って、ChromeやIE上でテストスクリプトを実行する方法 | MagicPod Tech Blog | MagicPod: AIテスト自動化プラットフォーム
                                                                              • テスト駆動開発の進化 - Digital Romanticism

                                                                                デブサミ関西2012での講演内容まとめ はじめに 今月、GOOS日本語版が発売されました。 実践テスト駆動開発 (Object Oriented SELECTION) 作者: Steve Freeman,Nat Pryce,和智右桂,高木正弘出版社/メーカー: 翔泳社発売日: 2012/09/14メディア: 大型本購入: 4人 クリック: 262回この商品を含むブログ (31件) を見る継続的デリバリーに続き、高木さんと一緒にお仕事をするのはこれで二冊目です。今回も多くの人に助けられて、目標としていたデブサミ関西での出版にこぎつけることができました。関係者の皆さま、どうもありがとうございました。 講演では触れませんでしたが、ここで「実践テスト駆動開発」というタイトルの由来について少し書いておきます。原書のタイトルはご存じの通り、"Growing Object-Oriented Softwa

                                                                                  テスト駆動開発の進化 - Digital Romanticism
                                                                                • テストの説明に安易に「正しく」とか書かない - Object.create(null)

                                                                                  みなさんテストは書いていますよね. 書いていなければふりだしに戻る. 例えば関数 add に対して, 以下のようなテストコードがあるとします. describe("add", () => { it("正しく計算できる", () => { expect(add(1, 2)).toBe(3); }); }); よさそうですね? もしよくないと思うのであればここから下は読まなくても大丈夫なくらい理解している方だと思います. 続いて関数名を変えただけのこちらをどうぞ. describe("sub", () => { it("正しく計算できる", () => { expect(sub(1, 2)).toBe(3); }); }); なんだか明らかに間違っている気がします. もしこのテストが通過してしまったとき我々はどうすればよいのでしょうか. 考えられるパターンは 2 つあります. 実装もテストも正

                                                                                    テストの説明に安易に「正しく」とか書かない - Object.create(null)