Bayonetta2 開発ブログ 『ベヨネッタ2』発売2周年&amiibo初公開! 2016.09.20
Bayonetta2 開発ブログ 『ベヨネッタ2』発売2周年&amiibo初公開! 2016.09.20
前書き 「一緒に働いている以上、プログラマのことを理解して仕事をしたい」そう考えている企画・ディレクションの方は経験則的に少なくない。 ノンプログラマから見て、プログラマの仕事はイメージが湧きづらく、何故その工程にそこまでのコストをかける必要があるのかわからない事が多い。 プログラマは作業の必要性を説明してくれるかもしれないけれど、専門用語も多いしイマイチピンとこなかったりする。 ここで重要なのはまさに「イメージ」だと思う。すなわちイメージを提供するための良質なメタファーだと思う。メタファーが良質であれば より直感的に理解できる。 実際メタファーの力はバカにならない。「Chef」も「Jenkins」も それぞれ 統一的な世界観が学習者の直感的な理解を後押ししてくれる。 というわけで、今回から数回に分けて なるべく「技術的な話」をせずに イメージを想起しやすいストーリーを導入することで プロ
こんにちは、だんだんブログ勘を取り戻していきたい和田です。このエントリは TDD Advent Calendar 2013 の 11 日目のエントリです。このエントリでは、最近行ったテスト駆動開発関連の講演や寄稿に関して、この機会にまとめておきたいと思います。 DevLOVE 現場甲子園 まず 11/9 にDevLOVE現場甲子園2013にて「テストを書く文化を育てる戦略と戦術」というタイトルで短い講演をさせて頂きました。DevLOVE 甲子園は楽天第2タワー大広間の四隅で最大四つの講演が同時に行われるという意欲的なイベントで、話す方も気合い(と声量)が必要な場でした。 この講演では、開発者が自動テストを書く文化が無かった組織に自動テストの文化を育てる際の姿勢、心がけについて短い時間でまとめました。そのときの講演資料がこちらです(ライセンスは CC BY です)。 テストを書く文化を育てる
色んな所で「テスト(ここではユニットテスト)を書かないのは小学生までだよねー」とか、もっと汚い言葉で言われたりするけど、いまだにうちのチームでは自分だけしか書かない現状が悩ましい。 Jenkinsさんが激おこになっても誰も何も反応しない。 もちろん、全部が書けるとも思ってないので、自分が不安なところとか、変更が多く入りそうなところとかを中心に書くようにしてる。一種の精神安定剤みたいなもん。 あるとき、一緒に働いてるエンジニアさん(ここではAさんとしておこう)に「ここ難しそうだから、テスト書いたほうがいいですよ」って話をしたら、「じゃぁ、工数かかっちゃいますね」って言われて結局書いてなかったな。 そうだよ。ユニットテスト書いたら工数かかるよ。それは純然たる事実。でも、再利用できないチェックシートを作ってやるよりもいいと思うんだけどね。しかもこの前に見せてもらったこのチェックシートも運用レベル
渡辺です。さる方面からテスト系のエントリーがまだか…と催促されたので、ユニットテストについて少し考えてみたいと思います。 最近、TwitterのTLをチェックしていると、JUnitを利用しているにも関わらず違和感のあるTweetや、原因をJUnitにして本来解決すべき問題から目をそらしているようなTweetを多く見かけます。そこで、JUnitをによるユニットテストに関するありがちな勘違いをまとめてみました。 なお、JUnitの部分は、RSpecでもNUnitでも適当に置き換えて読んでも構いません。 1.JUnitを使うことが目的という勘違い JUnitを利用すること自体を目的にしたところで何も得る事はありません。 ありがちな話ですが、「納品物としてJUnitのテストコード(または実行結果)を求められている」ことが理由でJUnitを利用しているならば、それは足かせでしかない可能性があります。
平素よりQA@ITをご利用いただき、誠にありがとうございます。 QA@ITは「質問や回答を『共有』し『編集』していくことでベストなQAを蓄積できる、ITエンジニアのための問題解決コミュニティー」として約7年間運営をしてきました。これまでサービスを続けることができたのは、QA@ITのコンセプトに共感をいただき、適切な質問や回答をお寄せいただいた皆さまのご支援があったからこそと考えております。重ねて御礼申し上げます。 しかしながら、エンジニアの情報入手方法の多様化やQAサービス市場の状況、@ITの今後のメディア運営方針などを検討した結果、2020年2月28日(金)15:00をもちましてQA@ITのサービスを終了することにしました。 これまでご利用をいただきました皆さまには残念なお知らせとなり、誠に心苦しく思っております。何とぞ、ご理解をいただけますと幸いです。 QA@ITの7年間で皆さまの知識
この記事は賞味期限切れです。(更新から1年が経過しています) JavaScriptユニットテスト一年生の私が、Nettuts+ のチュートリアルで知ったテストツール 「testem」のお陰で大変捗ったので是非お勧めしたく、ここで紹介してみます。 testem ってなに testem via GitHub : airportyh/testem Unit testing in Javascript can be tedious and painful, but Testem makes it so easy that you will actually want to write tests. 要するに、面倒なJSのユニットテストをより快適にしてみんなでハッピーにテスト書こうよ!というツールです。 testem自体はnode.jsベースで動作し、Jasmine/QUnit/Mochaに対応して
DRY原則に従おうとするほど、テストコードがどんどん読みづらくなる。 The RSpec Bookに答えがあるかと思って読んでみたものの、「あるある」と一言述べているだけだった。辛い。 テストコードが読みづらくなる例を示すために、1つRubyのライブラリをつくった。 値とパターンを与えてValidationを行う機能を提供するライブラリ。 実装60行、テスト120行なので、詳しく見たければすぐ読めると思う。 最近不本意ながらキラキラネームの命名力が上がってきたと思う。 avalon - A validator implementation for Ruby https://github.com/r7kamura/avalon 冗長だが読みやすい例 letもsubjectもローカル変数も何も用いずに率直に書いたテストコード例がこちら。 冗長だが読みやすく、テストコードを見ればライブラリの使い
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く