TDDは「開発者テストのTips集」t-wada氏が改めてひも解く“本質” - レバテックラボ（レバテックLAB）
プログラマ、テスト駆動開発者 和田卓人 学生時代にソフトウェア工学を学び、オブジェクト指向分析/設計に傾倒。執筆活動や講演、ハンズオンイベントなどを通じてテスト駆動開発を広めようと努力している。『プログラマが知るべき97のこと』（オライリージャパン、2010）監修。『SQLアンチパターン』（オライリージャパン、2013）監訳。『テスト駆動開発』（オーム社、2017）翻訳。『事業をエンジニアリングする技術者たち』（ラムダノート、2022）編者。テストライブラリ power-assert-js 作者。 日本におけるテスト駆動開発（以下、TDD）のエバンジェリストとして知られる和田卓人さん。TDDが世に出て20年あまりが経ち、開発者の間でその名が広がっています。その一方で、和田さんは「TDDの本来の意味を知らなかったり誤解したりしている人たちもかなり増えている」といいます。 今回は、TDDは本質
【翻訳】テスト駆動開発の定義 - t-wadaのブログ
このブログエントリでは、テスト駆動開発（TDD: Test-Driven Development）の考案者Kent BeckがTDDの定義を改めて明確化した文章を、許可を得たうえで翻訳し、訳者の考察を沿えています。 きっかけ 2023年の年末、テスト駆動開発（TDD: Test-Driven Development）の考案者Kent Beckは、substackにTDDに関するポストを連投して論戦を繰り広げていました。TDDはその誕生から20年以上が経ち、その間に「意味の希薄化」が発生して議論が噛み合わなくなっていました。意味の希薄化（Semantic Diffusion）とは、新しく作り出された用語が広まる際に本来の意味や定義が弱まって伝わる現象です。 私（和田）はTDDと関わりの深いキャリアを歩んできました。Kent Beckの著書『テスト駆動開発』の翻訳者であることもあり、TDDの正
Goのテスト安定性向上のためにFlakyなテストを再試行する機能を導入する提案 - tomato3713’s blog
Go言語にFlakyなテストへのサポートを追加する提案が面白かったので紹介します。 概要 Flakyなテストとは、コードに変更がないにもかかわらずテストが成功したり失敗したりと不安定な実行結果になるテストのことです。 テスト結果は本来なら全て成功ならリリース可能、1つでも失敗すればバグがあるのでリリース不可のようにリリースの可否を判断するための情報です。 そのため、不安定なテストは書かないようにすることが大前提です。 しかし、実際にはflakyであるとわかっていても修正が難しかったり、修正するための時間がないのでそのまま残すという判断をすることもあります。 Flakyなテストは削除するというのも手ではありますが不安定であってもテストが無いよりはマシとして残すこともあると思います。 github.com この提案では、Flakyなテストを扱うための機能を追加するものです。 初めの提案内容は、
Learn Go with Tests: テスト駆動開発を体験しながら Go を学ぼう - kakakakakku blog
TDD（テスト駆動開発）を体験しながら Go を学べる学習コンテンツ「Learn Go with Tests」を紹介する❗️全てのコンテンツを実施してみて，非常に良かったのでまとめることにした💡 Go に入門できる TDD のサイクル (Red / Green / Refactor) を体験できる コンテンツは "35種類" もある 無料で学べる GitBook (GitHub) に公開されている 日本語対応 英語版 📚 quii.gitbook.io 日本語版 📚 andmorefine.gitbook.io コンテンツ一覧 なんと「35種類」もコンテンツがある❗️ Go fundamentals 🚢 21種類 Install Go（Go をインストールする） Hello, world（Hello, World） Integers（整数） Iteration（反復、繰り返し） A
UnityでTDDハンズオンRepositoryを作っている - imog
最近更新したのでちょっと宣伝。 github.com なにこれ 最近、副業だったりプライベートなどでUnityを使う人でテストに興味ある方を対象にTDDについてお話する活動などをしています。その際に座学としてお話することもあれば、ハンズオン形式で実際に手を動かして書いてもらうということもあります。その際に使うサンプルリポジトリです。 ぜひお手元で考えながら書いてみてください。勉強会の資料などで使っていただいても大丈夫です。 なぜやってるのか ゲーム開発はソフトウェア開発の中でもかなり複雑性が高いと感じています。そして性質上変更頻度も高い。ゲームごとに作り方が変わる以上これは仕方ないことだと考えています。だからこそより変化に対応できるようにテスタビリティの高いコードになっていてほしいと考えていますがその難易度、そしてそもそものテストコード文化というものがないためにテストコードが書かれているこ
機械学習によく使うPythonのコード一覧まとめ | AI入門ブログ
AI機械学習を用いた経営問題の解決や幅広い業種へ多数のコンサルティングの経験を持つ。AIプロジェクトに関するコンサルティングだけではなく、AI人材の育成、会社全体のDX化など幅広い分野で活躍中。AIに関わる講演を多数行なっている。 今回は機械学習でよく使うPythonのプログラムコードをアルゴリズム別に紹介していきます。 そして、機械学習といえばScikit-Learn。Scikit-Learnでよく使うコードを紹介します。 最後におまけとして、PandasやNumpyでよく使うプログラムコードも紹介します。 これらのプログラムコードはコピペで利用できるのでブックマークしておくことをおすすめします！ これからエンジニアを目指して機械学習のPythonを学びたい方、エンジニア入門としてプログラムコードを書きたい方はこの記事を参考にしてください。
Introducing Rome
We’re excited to announce the first beta release and general availability of the Rome linter for JavaScript and TypeScript. This is the beginning of an entire suite of tools. Rome is not only linter, but also a compiler, bundler, test runner, and more, for JavaScript, TypeScript, HTML, JSON, Markdown, and CSS. We aim to unify the entire frontend development toolchain. Rome is a monolithic tool con
【初心者向け】テストコードの方針を考える（何をテストすべきか？どんなテストを書くべきか？） - Qiita
はじめに 「テストコードを書きましょう」とはよく言われるし、テストコードが大事だってことも理解できるんだけど、何をテストしたらいいの？どんなテストを書いたらいいの？と迷っている初心者プログラマさんは意外と多いのではないでしょうか？ そんな方たちに向けて、この記事では僕が普段意識しているテストコードの方針を紹介します。 おことわり 本来であれば具体的なコード例も豊富に入れたいところなのですが、かなり時間がかかってしまうので、いったん文章メインで記事を公開します。 もしかすると、そのうちコード例も一緒に盛り込んだ「リッチバージョン」を公開するかもしれません。 この記事の前提条件 この記事ではあくまで、「今現在、筆者が仕事で書いているテストコードの方針」です。 そのため、状況が異なると適用しづらい方針も出てくるかもしれません。 筆者は以下のような現場でコードを書いています。 月額定額で、お客様と
『テスト駆動開発』を写経するための環境構築 - ろくにメモ
はじめに このエントリは『テスト駆動開発』を写経しようと思ったものの、環境構築から始めなければならない人向けに書きました。 テスト駆動開発 作者: Kent Beck,和田卓人出版社/メーカー: オーム社発売日: 2017/10/14メディア: 単行本（ソフトカバー）この商品を含むブログ (1件) を見る まず、私の Java に対する習熟度についてですが、Java言語プログラミングレッスン 第3版(上) Java言語を始めようの上下を読破した程度で、Java 周りの開発環境は全く分かっておらず、Eclipse を軽く触ったことがある程度です。 また、テスト駆動開発や自動テストについては、興味はあったものの実際に手を動かして使ったことはないレベルなので、『テスト駆動開発』を写経して実際に体感してみようと思い購入しました。 ですが、いざ読み始めてみると「Eclipse で JUnit の使い
A guide to TDD a React/Redux TodoList App — Part 1 | HackerNoon
Part 1 — You’re here now. Part 2 — Link. Part 3 — Link. Part 4 — Link. This tutorial assumes some knowledge of JavaScript, the front end, test-driven-devlopment and the node package manager, with little-to-no experience of React/Redux. It’s my opinion on how it should be done at this very basic level while you’re still learning, and it should at the very least open avenues for you to pursue your o
FizzBuzz 問題をテスト駆動型開発で実装する (実践編) - Qiita
2017.07.02 編集しました。 先日投稿した準備編に引き続き、今回は実践編として FizzBuzz 問題の TDD を進めていきます。 準備編のおさらいと実践編の流れ TDD のメリット 動く綺麗なコードを実現出来るため (Clean code that works)。 実装を終えてから、テストで出たバグの影響範囲全てを修正していくという手戻りを少なくできるため。 保守性の高い設計を実現出来るため (テストしやすい == 変更に強く保守性が高い、テストしにくい == 設計改善の余地あり) FizzBuzz 問題の要件 要件 内容
FizzBuzz 問題をテスト駆動型開発で実装する (準備編) - Qiita
先日、Microsoft の開発者向けイベント de:code2017 に初参加しました。 最新の技術動向から、レガシー系開発現場をどうマネジメントし変えていくか、と幅広いテーマの話を聞くことが出来、とても面白かったです。 中でも DO03 50 分でわかるテスト駆動開発 というセッションのライブコーディングの題材であった、FizzBuzz 問題のテスト駆動開発 がとても印象的でした。 そこで、そもそもテスト (単体テスト) とは？ から振返りつつ、自分なりに実践してみました。 実践内容を順追っていくと長くなりそうなので、準備編と実践編の 2 つに分けて投稿します。今回は、準備編です。 単体テストとは 一言で言うと 単体テストとは、クラスやメソッド等の小さな単位でプログラムが仕様書通りに動作するかを確認するテストです。 単体テストの手法 主に、以下の 3 つに分けられます。 機能確認テスト
Infrastructure as Codeにおけるテスト駆動開発実践入門(上) - Qiita
Infrastructure as Codeにおけるコード開発にテスト駆動開発を導入する具体的な方法を全二回に分けて説明します。(上)ではIaCとは何か、テスト駆動開発とは何かについて概要を説明します。 Infrastructure as Codeにおけるテスト駆動開発実践入門(下)はこちら はじめに クラウド/コンテナ技術の登場により、ITインフラは頻繁に作っては捨てられる時代になりました。このような時代において、ITインフラの構成管理を従来通り手動で行うことは不可能です。なぜなら次のような事態が起こるからです。 頻繁にITインフラの構成が変わるため、手動で構成管理すると管理コストが膨大になる 管理表の反映し忘れにより、管理表に記載されているITインフラの構成と実際のITインフラの構成が乖離する そこで近年Infrastructure as Code(IaC)という技術が注目を集めていま
気負わず普通にテストしよう
はじめに これはシステムエンジニア Advent Calendar 2016の22日目の記事です。 色んなプロジェクトでのテスト体験や自分で学んだことをもとに、ポエムを書きます。 言いたいこと 普通にテストをこなそう 面倒だと感じたら、テストの設計か作業プロセスに問題があるから見直そう テストでは検証したいことを決めて、それに集中しよう ソフトウェアテストについての知識はざっと知っておこう 前提 本来はSIの現場で考えた場合、 UAT(受け入れテスト)やST(システムテスト)などにも言及すべきかもしれませんが、 あくまで僕個人という開発者目線なのでUT、ITが中心の内容になっています。 なんで作業が捗らないんだろう？ Javaを用いた金融系の業務システムをつくっているある日でした。 自分の作業がなんか思ったように進まないなぁということに気づきました。 「何に時間を使っているんだろう？」 な
ふつうのユニットテストのための７つのルール - ブログなんだよもん
最近、久しぶりにコードレビューをすることが増えたのですが、UnitTestのコードを見るとヒドイ部分が多く残念な気持ちになることもあります。 原因のひとつとして、プロダクトコードと違いテストの書き方をあまり書き方を明文化してなかったのが悪かったなと思い、とりあえず明文化してみました。 今回は、命名規則とかそのレベルまではいかず「ユニットテストかくあるべし」ってところまでをまとめます。正直、これ守ってくれたらあとは好みの世界もあるしね。 追記： テクニカルな部分も最低限ですがQiitaに記載しました。 qiita.com 追記： もうちょっと大上段の規約に関してもまとめてみました。 koduki.hatenablog.com 前提 ここではユニットテストを関数レベルのテストをJUnitのような自動テストツールで取り扱う場合に限定します。 また、Mavenでビルド時は常にテストを回すことを想定
ReactでTDD（テスト駆動開発）を始めよう : 環境構築からテスト作成、機能実装までの詳解ガイド | POSTD
最小限の設定のTDD手法を使い、「何をテストすべきか？」から、よくある落とし穴の避け方まで、Reactコンポーネントをテストする方法を学びましょう。 導入 まず、 React を触ったことがあり、更にはいくつかのテストも書いた経験があるとしましょう。それでも、コンポーネントをどうテストするのが最善なのか、よく分からないかもしれません。どこから始めるのでしょう。具体的には何をテストすればよいのでしょうか。 いくつかのReactコンポーネントは簡潔過ぎて、そもそもテストが必要なのかすらはっきりしません。 AngularからReactに乗り換えた 人なら、テストには愛憎のような思いがあるかもしれません。 確かに Angular にはテストを支援するツールがたくさんありますが、同時にテストを書くのが難しくなる可能性があります。冗長ながら省略できない定型コードが多々ある上、 $digest の呼び出
test-kitchenでインフラのTDDに挑戦[Rails/nginx/MySQL/rbenv]
これまでVagrantやChefをつかってインフラのコード化を勉強してきましたが、今回はさらに一歩進めてServerspecを使ったインフラのテストと、『test-kitchen』を使ったTDDにチャレンしてみました！ 慣れてくるとtest-kitchenのコマンドで設定をやり直し => インフラのテストがソースコードを書くような感覚で、インフラを構築できるのがすごく心地良かったです。 ようやくですが、localのvagrantと『AWS EC2』、『Digital Ocean』に対応しました。コマンドひとつでChefを適用したり、Serverspecでリモートの環境をテストできます！ (05-02 08:35) Rubyサーバ・デプロイまでのチェックリストを追加 🐝 今回のソースコードVagrant/Digital Ocean/AWS EC2上にnginx/MySQL/rbenv/Ru
![test-kitchenでインフラのTDDに挑戦[Rails/nginx/MySQL/rbenv]](https://cdn-ak-scissors.b.st-hatena.com/image/square/c2ea7e72d0d7f3ba6c237909f321e67ffbdaa24e/height=288;version=1;width=512/https%3A%2F%2Fmorizyun.github.io%2Fimg%2Fog_image.png)
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
開発効率を上げるテスト設計
GitHub - quangv/shirt-sizes: React+Redux, shirt size app (Bing API dead)
GitHub - donnemartin/interactive-coding-challenges: 120+ interactive Python coding interview challenges (algorithms and data structures). Includes Anki flashcards.
