Build the skills your teams need Give your teams the O’Reilly learning platform and equip them with the resources that drive business outcomes. Click on a feature below to explore. Trusted content Live online events Courses Interactive learning Certification prep O’Reilly Answers AI Academy Assignments Insights Dashboard Trusted content you can count on More than 60K titles from O’Reilly and nearl
Test-driven development (TDD) is a concept that's had a lot of attention in recent years. It is a practice of baking your tests right into your everyday coding, rather than leaving them as an afterthought. In this post, I will introduce the core concepts of TDD. The whole process is very simple to get to grips with, and it shouldn't take too long before you wonder how you were able to get anything
RSpec の入門とその一歩先へ がとてもよい記事だったので、 Python で写経させてもらいました。 https://github.com/methane/pytest-tut Ruby コミュニティと Python コミュニティの考え方の違いも見えて面白いと思います。 環境は Python 3.3 で、実行には py.test コマンドを使いましたが、 py.test の機能は特に使っていないので nose でもなんでも大丈夫です。 ファイルの作成 まずは空の実装とテストを作ります。 message_filter.py class MessageFilter: pass message_filter_test.py 最初のテストを書く py.test は .should といったメソッドを勝手に生やしたりはしません。普通に assert 文を書きましょう。 --- a/messege
今回はライフゲームTDDその4、その1、その2と、その3で誕生の実装ができました。基本的な枠組みはできているので、完成までは間近です。 しかしあらためてコードを眺めてみると、特にテストコードのほうがゴチャゴチャして読みにくくなっています。プロダクトコードにも、リファクタリングの余地があるかもしれません。TODOリストにも「テストをわかりやすく修正する」とあるので、先に進む前に直してしまいたいと思います。 テストコードを眺めて、まず気になるのがテストのフィクスチャを作成するところ、すなわちテストに必要な準備をするところで、特にテスト用のデータとしてCellをいくつか作っている箇所が、似たような処理をコピー&ペーストで書いているのがイヤな感じです。 なにをしてるのか読み取りにくい 大事な情報が、雑多なコードに埋もれてしまって、把握できない コピー&ペーストのため後で直すのが大変 とりたてて難し
その1、その2と続いて、今回はライフゲームTDDその3です。なかなか完了しない、誕生の処理を完成させたいと思っておりますが、どうなることやら。 前回はスパイクをへてCellクラスを抽出し、TDDで実装しました。このあたりのコーディング、本来はTODOリストに積みながらやったほうがよかった気がします。後知恵は正しいものなので、いまさらですがTODOリストに(もう終わった)タスクを書いておきます。 初期パターンを渡せる グリッドのデータ構造をスパイクする Cellを実装する 死んでいるセルに隣接する生きたセルがちょうど3つあれば、次の世代が誕生する。 <- いまここ 生きているセルに隣接する生きたセルが2つか3つならば、次の世代でも生存する。 生きているセルに隣接する生きたセルが1つ以下ならば、過疎により死滅する。 生きているセルに隣接する生きたセルが4つ以上ならば、過密により死滅する。 テス
さて、前回は誕生のテストを書いたところまででした。ここからは、誕生の処理を実装します。 テストの書き方によっては、中央の1セルだけ考えれば済んでいたかもしれないのですが、3x3のグリッド全体をちゃんと対応しなくてはいけなくなってしまいました。マジメにやろうと思うと、まずは文字列で持っているパターンを内部処理の都合がいい形にしてやるほうがよさそうです。 では、どんなデータ構造が「内部処理に都合がいい」でしょうか? ここはコードに語ってもらいましょう。データ構造をあまり想定せず、誕生のロジックを先に書くことにします。そこから、どういうふうにデータがアクセスできると便利か導き出しましょう。ことによるとテストを追加することになるかもしれません。 誕生のルールは「周囲にちょうど3つ生きたセルがいる」です。このロジックは簡単です。 life.py: def will_born(self, neighb
アジャイルなソフトウェア開発を導入する手伝いという仕事の中で、ペアプロでTDDをやってみせるという機会がよくあります。ここ最近のバディであるid:haru01と組んで、ライフゲームをやってみせるのが定番化しています。 ライフゲームをテーマにしてどんなふうにTDDを進めるのか、これから簡単に紹介していきたいと思います。ベーシックな手法のみで進めるので、モック(テストダブル)とか、データドリブンテストとかそういうことはしません。言語はPythonですが、誰にでも読みやすいのがPythonのいいところなので、Pythonを知らなくても理解できるんじゃないかと思います。 ライフゲームにはWikipediaにもあるように、誕生・生存・過疎・過密の4つのルールがあります。TDDでライフゲームを書くには、この4つをもとにTODOリストを作ります。 死んでいるセルに隣接する生きたセルがちょうど3つあれば、
Test-driven development (TDD) is an iterative process where tests are written before code to validate requirements. It follows the "red-green-refactor" cycle: write a failing test, write code to pass the test, refactor code. The document demonstrates TDD with a palindrome checker function, writing multiple tests to handle different cases before refactoring the code. Unit testing frameworks like un
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く