Pythonで学ぶ 基礎からのプログラミング入門(34) Pythonのテスト手法
今回からはプログラムを書くというよりも書かれたプログラムが期待どおりに動いているかどうかを確認する手法について扱います。 確認する手法はおおまかに2つあり、ひとつはプログラムを「書いている段階」でそれが期待どおりに動くかどうかを確認する「テスト」と呼ばれる手法です。もうひとつは書かれたプログラムが期待どおりに動いていないことがわかった「あと」で行う「デバッグ」と呼ばれる手法です。 あまりにもバグだらけのコードをデバッグするのは時間がかかる大変な作業なので、理想的には「現在開発している小さいパーツ単位でのテスト」をパスしたコードをどんどん結合していくというのが一般的な開発の流れになると思います。テストで見つかった「パーツを書いているとき」の問題の修正は比較的容易な場合が多いです。 テストに通ったうえでトラブルが発生した場合に、デバッグで何が原因で問題が発生しているかを特定し修正します。デバッ
小さく始める JavaScript のテスト - Qiita
JavaScript のテスト 書かないと怒られるし、書きたいとは思っているが、書くまでの敷居がやたらと高くなってしまった気がしている人へ。 最小のテスト 本質的にテストを書くのにフレームワークはいらない。 assertion だけあればいい。 isomorphic にしたいなら、 node の assert モジュールすら使わず console.assert だけで書ける。 // assert function assert(actual, expected) { console.log('.'); console.assert(actual === expected, '\nact: ' + actual + '\nexp: ' + expected); } function TestSum() { assert(1+2, 3); } // exec TestSum(); あとは普通に
Friendly - Windowsアプリのシステムテスト自動化 - ささいなことですが。
はじめに これはソフトウェアテストあどべんとかれんだー2014 - connpassの12/12の記事です。 12/9は@PoohSunnyさんのtesting - 地味だけどGebをgroovyにしている5Tips #SWTestAdvent - Qiitaでした。 Friendlyの紹介記事です。 自分のライブラリの宣伝ですみません。よろしくお願いします！ Windowsアプリ操作用ライブラリです。 FriendlyはWindowsアプリを.Netのプログラムから操作するためのライブラリです。 Win32、WinForms、WPFに対応しています。 （ストアアプリ用は特殊でまだα版です） Win32もいけますが、.Netの方が得意ですね。 僕自身もWindowsアプリのシステムテスト自動化をやっているのですが、自分が「安定動作する」システムテストを「簡単に」作るために作成しました。 通
超テスト入門 〜 サブルーチン復習とrequire, use - Qiita
この記事は Perl入学式 Advent Calendar 2014 の 5日目です。 こんにちは。サポーターさせていただいてます まっすー（@trapple ）です。 今日は昨日までと少し流れを変えて、普段のPerl入学式と同じような内容で行きたいと思います。 今年のPerl入学式の進行具合ですと、第4回サブルーチン/正規表現が終わったり終わらなかったりな進行具合だと思います。 今回はそのサブルーチンをちょっと発展させた内容になります。 サブルーチンまだ習ってないよ！ or 忘れちゃったよ！って人はまずは講義資料に目を通してみてください。 復習問題 それでは簡単な復習問題からスタートします。 mon, tue, wedといった3文字英語表記の曜日を引数として受け取り、月曜日, 火曜日, 水曜日といった日本語3文字表記の曜日を返すサブルーチンtranslate()を作ってください。 標準入
テスト全体の良い書き方について。 #swtest_jp - うさぎ組
概要 テストをつくるときにどうやって書いたらいいのか困るという話をよく聞きます。とても簡単な例ですが、これをするだけでもずいぶんと違うという意味で、自分がよく使う例を書いてみます。（実際にはリスクベースドテストとして成立させるために更に項目を追加したものを使っています。ですが、基本はこの形であり、ここにある考え方が重要だと思っています。 つまり、ツールを使えばもっと綺麗に出来るけど、まずはMarkdownでもExcelでもなんでもいいからやれる感じで整理できる方法というところです。 僕がこの考え方を気に入っているのは、プロジェクトのリスク管理手法とあまり違わないので、別にテストではなくて、例えば「こういった人が必要」とか「こういったツールがいる」とかになるという点です。 まとめすぎると「BDD-Styleに対して、リスクという親要素を加える」というくらいです。 構成のテンプレ 基本的に3段
【ノンプログラマ向け】プログラマの仕事内容を理解する(1) ～「テスト」という工程が必要な理由 | きのこる庭
前書き 「一緒に働いている以上、プログラマのことを理解して仕事をしたい」そう考えている企画・ディレクションの方は経験則的に少なくない。 ノンプログラマから見て、プログラマの仕事はイメージが湧きづらく、何故その工程にそこまでのコストをかける必要があるのかわからない事が多い。 プログラマは作業の必要性を説明してくれるかもしれないけれど、専門用語も多いしイマイチピンとこなかったりする。 ここで重要なのはまさに「イメージ」だと思う。すなわちイメージを提供するための良質なメタファーだと思う。メタファーが良質であれば より直感的に理解できる。 実際メタファーの力はバカにならない。「Chef」も「Jenkins」も それぞれ 統一的な世界観が学習者の直感的な理解を後押ししてくれる。 というわけで、今回から数回に分けて なるべく「技術的な話」をせずに イメージを想起しやすいストーリーを導入することで プロ
ユニットテストを書こう！ - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? ユニットテストを書こう！ ソフトウェアエンジニアにとって、ユニットテストは重要です。僕はなるべくユニットテストを書くようにしており、ソフトウェアエンジニアはもっとユニットテストを書くべきだ、と考えています。ここで言及している「ユニットテスト」は、単なる「テストコードによる自動化」全体を指すのではなく、「テストから見えてくるグーグルのソフトウェア開発」で登場した用語である「Sテスト」を指します。 「テストから見えてくるグーグルのソフトウェア開発」では、テストコードが対象とするプロダクションコード(製品コード)の規模、S、M、Lとサイズごと
1. Automated Testing - prog*sig
FirebugなどJavaScriptデバッガーはいろいろあって便利だけど、Humans are lazyだ。 デバッガーによるデバッグは手動で行っているので、そこにAutomated testingをもうけて自動化しよう。 JavaScriptの自動テストのソフトウェアの歴史は2001年のJsUnitまでさかのぼる。 2004年にSeleniumがでてきて、 JavaScript/web developmentは今も活気があるコミュニティだ。 ■1.1 The Unit Test Unitテストはコンポーネント単体で実行すべきであり、他のテストに依存するべきではない。 場合によっては単体で実行できるようにするためにmockやstubといったものを必要にするときがあるだろう。(この辺はPart III, Real-World Test-Driven Development in
Python 2.7に搭載の新unittestモジュールはスーパークール — TRIVIAL TECHNOLOGIES 2.0
みんなのIoT/みんなのPythonの著者。二子玉近く160平米の庭付き一戸建てに嫁/息子/娘/わんこと暮らしてます。月間1000万PV/150万UUのWebサービス運営中。 免責事項 プライバシーポリシー 先日リリースされたPython 2.7がなかなかいいかんじ。set型のリテラル，set/辞書内包表記やviewなど3.xからのバックポートを多く含んでいる。細かいところではネットワーク系モジュールのIPv6対応が進んでいたり，Python 2系最後のリリースとうたわれているだけあって，かなり意欲的なリリースとなっている。 なかでも，標準のunittestモジュールがものすごく大きな進化を遂げていて，かなり魅力的になっているので簡単に紹介したいと思う。 テストディスカバリ 単体テストは，たいていモジュールやクラス，または機能ごとに個別にファイルを作り，テストコードを書く。大抵のプロジェク
循環的複雑度 - Wikipedia
循環的複雑度（英: Cyclomatic complexity）とは、ソフトウェア測定法の一種である。Thomas McCabe が開発したもので、プログラムの複雑度を測るのに使われる。プログラムのソースコードから、線形的に独立した経路の数を直接数える。 手法としてではなく、そのコンセプトは文章の可読性（複雑度）を測定する Flesch-Kincaid Readability Test に似ている。 循環的複雑度は、プログラムの制御フローをグラフとして描くことで計算される。グラフのノードはプログラムのコマンドに相当する。2つのノードを結ぶ有向エッジは、第一のコマンドを実行後、次に第二のコマンドが実行される可能性があることを示している。
pythonco(ぱいそんこ)の日記 - 2006-10-15 #doctest
doctestを使ってみます。doctestはドキュメンテーション文字列の中から >>> で始まる文字列を探してきて実行します。実行結果が >>> の次の行と一致した場合、テストは成功です。 # a.py import doctest def foo(a, b): '''return a+b >>> foo(10, 1) 12''' return a+b def bar(a): '''return 2**a >>> bar(11) 2048''' return 2**a doctest.testmod()実行結果は以下のようになります。 > python a.py ********************************************************************** File "a.py", line 6, in __main__.foo Failed
2006-10-14
assertを使ってみます。 a = 0 for i in range(5): a += i assert a < 30, a print a a = 0 for i in range(10): a += i assert a < 30, a print a実行結果は以下のようになります。 10 Traceback (most recent call last): File "a.py", line 10, in ? assert a < 30, a AssertionError: 36assertは assert 式1, 式2のように使います。式1が真の場合は何もしないのですが、式1が偽の場合は例外AssertionErrorを送出し、式2を評価します。実行結果を見ると最初のループは a < 30 が真のまま終了し、print a が実行されていることがわかります。二番目のループでは途中
unittestの書き方 - Λάδι Βιώσας
pythonのunittestのやり方をよく忘れるのでメモ＆まとめ。 テストケースを作る import HogeModule # テスト対象のモジュール import unittest class testHogeModule(unittest.TestCase): # HogeModuleテストケース def test_foo(self): # foo関数のテストメソッド self.assertEquals(HogeModule.foo(1, 2), 3) def test_bar(self): # bar関数のテストメソッド ・・・・ テストメソッドは、prefixにtestを付ける。そうするとフレームワーク側で勝手に呼び出してくれる。テストの際、初期化や終了処理などが必要な場合、それぞれsetUpメソッドとtearDownメソッドで行う。 テストスイートを作る テストケースを書いたら
はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
https://www.freia.jp/taka/blog/347/