A compilation of outstanding testing articles (with JavaScript) | Practica.js
About the sweet and powerful 'use case' code patternA compilation of outstanding testing articles (with JavaScript)Testing the dark scenarios of your Node.js applicationPractica v0.0.6 is aliveIs Prisma better than your 'traditional' ORM?Which Monorepo is right for a Node.js BACKEND now?Popular Node.js patterns and tools to re-considerPractica.js v0.0.1 is alive
Viper
Viper (Verification Infrastructure for Permission-based Reasoning) is a language and suite of tools, providing an architecture on which new verification tools and prototypes can be developed simply and quickly. Viper is being developed at ETH Zurich in close collaboration with the team of Alex Summers at UBC. Viper comprises a novel intermediate verification language, also named Viper, and automa
20 万行超のコードベースをテストせずにリファクタリングリリースした話 - MonotaRO Tech Blog
こんにちは、鈴木です。 20 万行を超えるアプリケーションのほとんど全てのソースコードを変更し、テストを行わずに本番リリースしました。 「それってテストいるんですか？」問題 いきなりですが質問です。ソースコードを 1 バイトでも変更したら再テストする必要はあるでしょうか。「絶対に再テストすべき」という方もいれば、「状況によるしケースバイケースかな・・」という方もいらっしゃると思います。 ケースバイケースと考える方は、どのような場合にテストを行わなくて良いと考えるでしょうか。例えば、コメント内の誤字を修正した場合はどうでしょうか。ローカル変数の名前を typo していたので修正した場合、デッドコードを削除した場合はどうでしょうか。 こんなことがありました ある日、Python のソースコードを眺めていると、「# $Id」のような CVS 時代のコメントがありました。いまやソースコードは Gi
状態遷移テスト - state transition testing -
状態遷移テスト - state transition testing - WACATE 2018 夏での状態遷移テスト説明資料。 WACATE 2018 summer http://wacate.jp/2018/summer/program.html
テストを書くか書かないかの判断の話
writing_unit_test.md ユニットテストでテストを書くか書かないかの判断の話 お題 メソッドの出力の結果が、true か false のどちらでも返ってくる可能性がある場合、assert 文を書く時は true の場合だけで良いのだろうか テストとは まず、基本の考えとしてなぜテストをするのか？というのがあります。 テストとは、エラーをみつけるつもりでプログラムを実行する過程である。(via ソフトウェアテストの技法 [Glenford J. Myers]) という言葉のとおり、最小の手間でプログラムのエラーを見つけ出そうとする試みがテストです。裏を返せば、エラーが見つかる可能性が低いのにすべてのことを試すのはテストではありません。 判断するときの論点 いくつかこれを判断するときの論点があります (Boolean に限らず、「そのテストは必要か？」と考えるときの観点ともいえ
これであなたもテスト駆動開発マスター！？和田卓人さんがテスト駆動開発問題を解答コード使いながら解説します～現在時刻が関わるテストから、テスト容易性設計を学ぶ #tdd｜CodeIQ MAGAZINE
和田卓人さんによるテスト駆動開発問題解説の寄稿です！ バグのないよいコードを書くには、よいテスト設計が重要です。今回は現在時刻に関する問題と、その問題で提出された実際の解答コードを紹介しながら、どのようにテスト設計し開発していくのかを解説していきます。 ゲスト解答による解答コードも公開中！ by CodeIQ運営事務局 はじめに こんにちは、和田(@t_wada)です。今日は先日出題させていただいたTDDに関する問題の総評を行いつつ、テスト容易性設計について考えてみたいと思います。 問題文 私が出した問題は、以下のようなものでした。 問1. 下記の仕様をテスティングフレームワークを使ってテストコードを書きながら実装してください。 【仕様1】 「現在時刻」に応じて、挨拶の内容を下記のようにそれぞれ返す機能を作成したい。 (タイムゾーンはAsia/Tokyoとする) 朝(05:00:00以上
単体テストガイドライン — The Pylons Project Documentation (翻訳)
単体テストガイドライン¶ Pylons プロジェクトは、このドキュメントの元となった Tres Seaver によって書かれた Avoiding Temptation: Notes on using unittest effectively に倣ったユニットテスト教義をかなり厳格に守っています。 Note このドキュメントは、ほとんど排他的に 単体 テストを扱います。 結合テストまたは機能テストに対しては私たちは特別の教義を持っていません。 しかし、下記の tips の多くはその文脈でも再利用できます。 悪い単体テストを避けるための tips¶ ある人々は “don’t repeat yourself” をむやみに信じてきました (drink the KoolAid): 私たちは、ほとんどの場合にはコードの繰り返しをしないことが 美徳であることに同意します。しかし、単体テストコードはその例
Rails で、Controller に定義されている action を一度に取得する方法はありますか？ - QA@IT
平素よりQA＠ITをご利用いただき、誠にありがとうございます。 QA＠ITは「質問や回答を『共有』し『編集』していくことでベストなQAを蓄積できる、ITエンジニアのための問題解決コミュニティー」として約7年間運営をしてきました。これまでサービスを続けることができたのは、QA＠ITのコンセプトに共感をいただき、適切な質問や回答をお寄せいただいた皆さまのご支援があったからこそと考えております。重ねて御礼申し上げます。 しかしながら、エンジニアの情報入手方法の多様化やQAサービス市場の状況、＠ITの今後のメディア運営方針などを検討した結果、2020年2月28日（金）15:00をもちましてQA＠ITのサービスを終了することにしました。 これまでご利用をいただきました皆さまには残念なお知らせとなり、誠に心苦しく思っております。何とぞ、ご理解をいただけますと幸いです。 QA＠ITの7年間で皆さまの知識
［動画で解説］和田卓人の“テスト駆動開発”講座 記事一覧 | gihyo.jp
第17回リファクタリングをどこまでするか、いつやめるか 和田卓人 2007-12-25
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
