フリーエンジニアのIT案件ならレバテックフリーランス
2016年11月3日（祝）、大田区産業プラザPiOにて開催された国内最大のPHPイベント「PHPカンファレンス2016」。レバテックフリーランスでは、カンファレンスセッションの登壇者のひとり・和田卓人氏にインタビューを実施しました。 テスト駆動開発の先駆者として知られる和田氏ですが、今回の講演テーマは「PHP7で堅牢なコードを書く-例外処理、表明プログラミング、契約による設計」。あえてテスト以外のテーマを設定した理由をはじめ、PHPの優位性や今注目している言語、初心者エンジニアへのアドバイスなど、幅広くお話を伺ってきました。 ＜この記事の要約＞ 1. PHPの良い点は、ゆるふわな言語に見せかけて堅牢なコードも書けるところ。悪い点は、覚えることが多くて難しいところ。 2. テストを書いていればコードの品質が高いわけではない。また、テストが書けないくらい問題を抱えたコードでも、中から改善してい
テストがうまくいかないプロジェクトに捧ぐ、正しいテストの考え方 - Qiita
この記事の対象者 プロジェクトでテストを書いている。(書いたことある) テストが重要らしい事は知っているが、テストの恩恵をそこまで実感できていない。 結局手動テストに依存したバグフィックスをしている。 はじめに 私はテストの設計手法、実装に関する知識は多く持っていましたが、知らなかったことはテストの考え方でした。 テストが重要らしいことを知っている人は多いと思います。 しかし、実際に恩恵を実感できていない人もいると思います。 事実、 テストが重要だと発信している人 と、 テストが重要らしいことを知っている人がいます。 後者の人は、とりあえずテストを書く事ができます。しかし、テストに時間を割く割りに、最終的には手動テストでバグを発見することに依存している事も多いかなと感じます。 世間ではテスト書くのが当たり前、テストは重要！という風潮であるのに、何故テストが重要であると実感できないのでしょう
できる開発者の酷いコードとのつきあいかた | readwrite.jp
ただの一行も酷いコードを書いたことがないというのは可能性としてあり得なくはないが、実際にはとても考えにくいことだ。 現実には、あなた自身も他の開発者と同じくセキュリティ欠陥を作ってしまったりUIの配置ミスなどをやってしまうことだろう。なにもあなたがダメな開発者だからというわけではなく、人間である以上しかたがないことなのだ。 開発者たちはみな人として仕方のない弱点を抱えていることから、「最高の開発者」と呼ばれる人々は自分が作るコードやインフラで起こりうる最悪の事態を想像し、それに備えている。以下、最高の開発者たちがおこなっていることだ。 大混乱を前提に考える数年前、Netflixが「Chaos Monkey」およびクラウドベースの管理ツール「Simian Army」の一部をオープンソース化した。かいつまんで言うと、Chaos Monkeyは、AWSインフラで幅広く動いているインスタンスをラン
プログラムに証明が付く日 | RANDMAX
この記事は「Theorem Prover Advent Calendar 2013」6日目の記事です。 http://qiita.com/advent-calendar/2013/theorem_prover 神田「野らぼー」にて、地下の薄暗い店内で… 「そう言えばこないだ隣で起こってたポインタオーバーラン、対応大変そうだったですけどちゃんと家に帰れてたんでしょうかね、新婚なのに…」 「ヌルポとかポインタオーバーランとか、どうして無くならないんだろうね。その時はみんな手を抜いてるつもりなんて毛頭なくて、一生懸命考えて大丈夫だと思ってるはずなんだけどね。レビューもして、それでも起こった後でみんなでソース見てみると、なんで気づかなかったんだよ！ってことになる。」 「人間って、そういうの苦手なんでしょうねきっと。ほら、『何かほかにありませんか』って聞かれても出てこないじゃないですか。静的な解析っ
double型のアサーションにおける罠 | DevelopersIO
渡辺です。 Twitterでこんなことに困っている方がいたので、ブログのネタとして扱ってみました。 @shuji_w6e Javaって+0.0と-0.0が区別されてるじゃないですか。それで+0.0=-0.0はtrueになるんですけど、assertThat(+0.0 is(equalTo(-0.0)))ってなるとassert違反しちゃうんですよね・・・ — キーチ (@keachcox) October 26, 2013 「いつからプリミティブ型で比較していると錯覚していた？」 プリミティブ型とプリミティブラッパークラス はじめにJavaのプリミティブ型とプリミティブラッパークラスについて説明します。 Javaは歴史的な経緯からすべてのデータをオブジェクトとして保持していません。boolean, int, doubleなどの幾つかの型はプリミティブ型と呼ばれ、オブジェクトとは異なる扱いになっ
Androidで別アクティビティを呼び出したことをユニットテストする方法 « wp.krks.net
この記事を参考にさせていただきました。 以下がサンプルコード。 やりたかったアクティビティからアクティビティの呼び出しが行われたかの確認のみに特化。 テスト対象コード。アクティビティを呼び出す方 package net.krks.android.junitsample; import android.app.Activity; import android.content.Intent; import android.os.Bundle; import android.view.View; import android.view.View.OnClickListener; import android.widget.Button; public class JUnitSampleActivity extends Activity { /** Called when the activity
AndroidアプリケーションをJUnitでテストする | Android開発メモ
作成したアプリケーションは、どのように動作確認していますか？ Androidには、Javaの単体テストのフレームワークである「JUnit」を使用することができます。今回は、その使用方法について説明します。 <1>アプリケーションの仕様を決める まず、作成するアプリケーションの仕様を決定しないといけませんが、今回は下のようなAndroidアプリケーションを作成します。 画面の一番上にEditTextを貼り付ける。 EditTextの下に、TextViewを貼り付ける。 EditText、TextViewの初期値は空文字。 TextViewの下には「コピー」という文字が入ったボタンを貼り付ける。 「コピー」ボタンは、EditTextに文字が入力されていない場合は、ボタンを押下することはできない（無効になっている）。 「コピー」ボタンを押下すると、EditTextの内容がTextViewにコピー
Androidアプリを“超”魅力的にする3種類のUIテスト
Androidアプリを“超”魅力的にする3種類のUIテスト：Androidアプリ開発テスト入門（3）（1/3 ページ） 日本Androidの会テスト部が、いままで培ってきたAndroidアプリ開発におけるテストのノウハウを、実際のテストコード例とともに紹介していきます 「UIのテスト」って何？ 本連載「Androidアプリ開発テスト入門」では、Androidアプリを開発している方のために、テストの基本的なノウハウを解説しています。第3回となる今回は、ユーザーインターフェイス（以下、UI）のテストについて解説します。 スマートフォンアプリケーションの特徴として、タッチ操作による魅力的なUIが挙げられます。Androidのアプリケーションの開発においても、UIの作り込みを求められることが多く、UIの品質の担保は大きな課題です。 本連載で扱うUIは、画面のレイアウト、画面遷移やイベントなど振る舞
「テスト自動化ツールを導入済みは8.5％、85％以上が検討していないか必要を感じない」 - カレーなる辛口Javaな加齢日記
注：テスト本リストは加筆修正した上で，改めて独立した項目に作り直した． → http://d.hatena.ne.jp/JavaBlack/20150926/p1 http://www.publickey1.jp/blog/12/8585.html http://www.keyman.or.jp/at/dev/debug/30004610/ 数値の正確さはともかく，だいたいそんなもんでしょう． 「スキルがないからPHP使ってます」「Javaは使ってるけどオブジェクト指向って何ですか？」みたいな現場だと，テストするスキルも人手も足りない． そもそもテストを知らない．テスト＝手動テストだと思っている． デバッグといえばデバッガでするものだと思っている． 導入するメリットが理解できない． テストをする人に，プログラミングのスキルや経験がない．ひどい場合には素質が無い．*1 導入するスキルがない．
愛せないコードを書くには人生はあまりにも短い
A empresa de tecnologia anunciou um novo smartphone com câmera aprimorada, processador mais rápido e bateria de maior duração. O dispositivo também possui tela maior e armazenamento expansível, com preço sugerido a partir de US$799. Analistas esperam que o aparelho ajude a empresa a aumentar sua participação no competitivo mercado de smartphones.
モックによるインターフェイスの発見 - Digital Romanticism
設計ツールとしてのモックの使い方について考える。 導入 先日、"Mock Roles, not Objects"の日本語版「ロールをモックせよ」を公開しました。この論文は2004年に書かれたもので、著者はSteve Freeman氏、Nat Pryce氏、Tim Mackinnon氏、Joe Walnes氏という豪華メンバーです。また、Steve Freeman氏とNat Pryce氏は『Growing Object-Oriented Software, Guided by Tests (Addison-Wesley Signature Series (Beck))』（いわゆるGOOS）の著者でもあり、"Mock Roles, not Object"で語られている思想はGOOSのベースになっているとも言えます。 今回は、この"Mock Roles, not Objects"（以下、MRnO
Selenium 中級者になろう （変数＋XPath＋JavaScriptを，テストケース中で利用する方法） - 主に言語とシステム開発に関して
回帰テストツール「Selenium」の中級 Tips。 初級の使い方については 今から３分で selenium の使い方を身に付ける (回帰テスト自動化) http://language-and-engineering.hatenablog.jp/entry/20081016/1224080409 selenium 主なコマンド一覧 http://language-and-engineering.hatenablog.jp/entry/20081016/1224123118 で入門のこと。 Seleniumのより便利な使い方として，下記で （１）変数の使い方 （２）XPathの使い方 （３）テストケース中へのjavascriptの埋め込み （４）Ajaxアプリのテスト方法 を学ぶ。 まず，まとめを掲載。そのあとで，実際のテストでどう役立つのか詳しく解説する。 まとめ 要素の指定方法まとめ
自動改札機の運賃計算プログラムはいかにデバッグされているのか？ 10の40乗という運賃パターンのテスト方法を開発者が解説（後編）
自動改札機の運賃計算プログラムはいかにデバッグされているのか？ 10の40乗という運賃パターンのテスト方法を開発者が解説（後編） 9月12日から14日のあいだ、東洋大学 白山キャンパスで開催された日本科学技術連盟主催の「ソフトウェア品質シンポジウム 2012」。オムロンソーシアルソリューションズ 幡山五郎氏の講演「自動改札機ソフトウェアの品質向上の取り組み 厳密な仕様、もらさないテストを目指して」。この記事では、そのダイジェストを紹介しています。 本記事は、前編、中編、後編の3部構成です。お読みのページは後編です。 大規模なテストをどうやって実行しているか 続いて、大規模なテストについて。 1000万件のテストパターンを作っても、それぞれのテスト結果の正解を人手で作っていたら追いつきません。なので、別々に運賃計算ソフトウェアを作って、その答えを突き合わせてチェックしよう、という話です。 例
自動改札機の運賃計算プログラムはいかにデバッグされているのか？ 10の40乗という運賃パターンのテスト方法を開発者が解説（中編） － Publickey
自動改札機の運賃計算プログラムはいかにデバッグされているのか？ 10の40乗という運賃パターンのテスト方法を開発者が解説（中編） 9月12日から14日のあいだ、東洋大学 白山キャンパスで開催された日本科学技術連盟主催の「ソフトウェア品質シンポジウム 2012」。オムロンソーシアルソリューションズ 幡山五郎氏の講演「自動改札機ソフトウェアの品質向上の取り組み 厳密な仕様、もらさないテストを目指して」。この記事では、そのダイジェストを紹介しています。 本記事は、前編、中編、後編の3部構成です。いまお読みのページは中編です。 自動改札機の制御は1000件くらいのテスト さて、次は間違えない自動改札機の話です。ここからソフトウェアの話になります。 1つは運賃計算。この切符はこの駅で降りられるのか、というもの。そしてもう1つは自動改札の制御。ランプを光らせるとか、切符を回収するとかです。 まずはその
自動改札機の運賃計算プログラムはいかにデバッグされているのか？ 10の40乗という運賃パターンのテスト方法を開発者が解説（前編）
自動改札機の運賃計算プログラムはいかにデバッグされているのか？ 10の40乗という運賃パターンのテスト方法を開発者が解説（前編） ふだん何気なく使っている鉄道。改札を降りるときにICカードを自動改札にかざすと、「ピッ」という音と共に一瞬のうちに運賃を計算してくれます。けれど、複数の路線を乗り継いだり、途中で定期券区間が挟まっていたりと、想像しただけでもそこには膨大な組み合わせがあります。それでも運賃計算プログラムはわずか一瞬で正しい運賃計算が求められ、バグがあったら社会的な一大事にもつながりかねません。 爆発的な計算結果の組み合わせがあるはずの運賃計算プログラムは、どうやってデバッグされ、品質を維持しているのでしょうか？ 9月12日から14日のあいだ、東洋大学 白山キャンパスで開催された日本科学技術連盟主催の「ソフトウェア品質シンポジウム 2012」。オムロンソーシアルソリューションズ 幡
極力ユニットテストを書かずに品質を確保する方法 - ひがやすを技術ブログ
今日のテストサミットで、できるだけユニットテストを書かずに品質を確保する方法について、ディスカッションします。 やり方を簡単に紹介すると、最初は、Programming First Developmentで、機能を実装して、ユーザに動かしてもらうってことをユーザの要件が固まるまで繰り返します。このときは、基本的にユニットテストは書きません。動かすことに集中します。 ユーザの要件が固まった(実装がほとんど終わった)ら、保守のためのドキュメントの一つとして、テストシナリオ(ユースケーステスト)を作って、テストを行います。そのテスト中に、バグが発見されたらその周辺のユニットテストを書いていきます。 これは、「バグは偏在(偏って存在)する」という特徴を利用して、一通り動かした後に見つかったバグの近くをテストしておけば、主なバグはつぶれるだろうという考えです。 これまでは、「ユニットテストは、できる
SQLiteのテストコードは4567万8000行！ 本体のコードは6万7000行
軽量なリレーショナルデータベースとして人気のSQLite。そのWebサイトに掲載されている「How SQLite Is Tested」の内容が、海外のプログラマなどのあいだで話題になっています。 3月に公開された最新バージョンのSQLite 3.6.23。本体のソースコードは約6万7200行（67.2KSLOC、Kilo Source Lines of Code：空行やコメントを除いた行数）なのに対し、テストコードはなんと4567万8300行（45678.3KSLOC）だと紹介されているのです！ これはテストコードが本体の約679倍もの大きさだということになります。 100％のブランチカバレッジ SQLiteコアのライブラリをテストするテストコードとして、以下の3つが紹介されています。 TCL Tests TCL Testsはもっとも古いテストコードで、TCL scripting lang
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
How to test Menu
Google Issue Tracker
Coveralls.io - Test Coverage History and Statistics