タグ

testに関するwtrmiyaのブックマーク (12)

  • プログラマの思索

    astahにタイミング図がサポートされたのでメモ。 【参考】 astah* 9.2リリースノート | astah タイミング図 | astah* 機能ガイド plantumlでタイミング図が描けるらしい: プログラマの思索 astahとPlantUMLを行き来できるastah* PlantUML Pluginが面白い: プログラマの思索 astah* Mermaid Pluginが公開された: プログラマの思索 Timing図 わかりやすくUMLタイミング図とは 【PlantUMLの使い方】PlantUMLでタイミングチャートを作成する - システムとモデリング UMLのタイミング図を使う機会は正直ほとんどないし、経験もない。 感覚的には、シーケンス図を横型にしたイメージを持っている。 ただ、ハードウェア設計者ならタイミング図をよく使うと聞いているので、どんな状況でどのように使うのか、調べ

    プログラマの思索
    wtrmiya
    wtrmiya 2013/12/03
  • [iPhone][TDD]SenTestingKit使い方 - l4l

    XCodeにデフォルトで含まれるユニットテストフレームワーク「SenTestingKit」をiPhoneアプリ開発で利用する方法を忘れないようにメモ。大枠の設定&実行まで、コーディングレベルのアサーションの種類や使い方は別途書く。 参考記事 iOS Development Guide: Unit Testing Applications まずプロジェクトの作成。任意のプロジェクトでユニットテストが可能(プロダクト用とユニットテスト用のプロジェクトを分ける必要がなく後述するターゲットで分ける)、なので適当にWindow-based Applicationを選択。 プロジェクト名は任意でOK、「UnitTestSample」として保存。 初期状態のプロジェクトリソースはこんな感じ。 ユニットテストはビルド時にXcodeで行う「Logical Tests」と、実機で行う「Applicati

  • RSpec のすごいところ - kなんとかの日記

    (注: 以下の内容は、RSpec ユーザの間で広まっていることでもなく、もちろん RSpec 開発チームの公式な見解でもなく、あくまでワシの個人的な見解です。) RSpec のすごいところは、コードに対してではなく仕様に対してテストを書くことを明確にしたことだと思う。何を今さらと言われそうだけど、今さらになってようやく気づいたニワトリ頭ですまんかった。 ワシも最初は、「assert_equal(expected, actual)」のかわりに「actual.should == expected」と書くかっこよさに目を奪われて、テストコードを自然言語に近い形で記述するのが RSpec のすごいところだと勘違いしてたし、それが「TDD (Test Driven Development)」から「BDD (Behaviour Driven Development)」へという新しい潮流だと勘違いしてた

    RSpec のすごいところ - kなんとかの日記
    wtrmiya
    wtrmiya 2010/08/19
  • テストコードの書き方 (unshiu)

    理想をいえば全ての可能性を網羅することが最適ですが、事実上不可能です。 大事なのは重要もしくはミスが起こりやすいところが網羅されているかです。 少なくとも以下のポイントに当てはまるところは重点的にテストコードを書くべきです。 メソッド内にコメントを書かなければ理解できないようなメソッド ロジックが複雑なためにどうしてもコメントで補記しないとわからないメソッドはどうしても存在してしまいます。 こういったメソッドはテストを書くことでさらに仕様を明確にできます。 2回以上修正したメソッド なんのミスもなく、書いた後に1度も修正しないようなメソッドよりも、書いた後に拡張した、なんらかのミスで修正したメソッド に重点的にテストは書くべきです。 外部アプリケーションと連携する部分 こちらが何を想定して何が想定外なのが明確になります。 外部アプリケーションの仕様が先方都合や提供もとの都合で変更される可能

    wtrmiya
    wtrmiya 2010/04/21
  • xUnit Test Patterns読書会 - FrontPage

    wtrmiya
    wtrmiya 2009/05/27
  • モデル駆動型ソフトウェアテストの可能性

    テスト現場の生の声をお伝えするために ソフトウェアテストに片足だけはまっている人、頭からつま先までずっぽりはまっている人……、テストとのかかわり具合はエンジニアによってそれぞれでしょうが、テストと全然かかわりを持たないという技術者はおそらくいないでしょう。テストへの取り組み方は十人十色なだけに「テスト」と聞いて、自慢するのか愚痴をつぶやくのか、あるいはきびすを返して逃げ出そうとするのかいろいろな反応があると思います。 立場こそ違いますが、テストが大事だという認識はほとんどのエンジニアが持っていると思います。しかし、プログラミング手法や開発手法などのように、スキルアップのための材料が簡単には得られないという印象を(テストに対して)持っているエンジニアが多いようです。テストに関する日語の情報は豊富とはいい難いのが現状ですし……。 「テストに興味を持って活動しているエンジニアは、テストのことを

    モデル駆動型ソフトウェアテストの可能性
    wtrmiya
    wtrmiya 2009/05/22
  • GT Nitro: カーレーシング・ドラッグレーシングゲーム - Google Play のアプリ

    GT Nitro: Car Game Drag Raceは、典型的なカーゲームではありません。これはスピード、パワー、スキル全開のカーレースゲームです。ブレーキは忘れて、これはドラッグレース、ベイビー!古典的なクラシックから未来的なビーストまで、最もクールで速い車とカーレースできます。スティックシフトをマスターし、ニトロを賢く使って競争を打ち破る必要があります。このカーレースゲームはそのリアルな物理学と素晴らしいグラフィックスであなたの心を爆発させます。これまでプレイしたことのないようなものです。 GT Nitroは、リフレックスとタイミングを試すカーレースゲームです。正しい瞬間にギアをシフトし、ガスを思い切り踏む必要があります。また、大物たちと競いつつ、車のチューニングとアップグレードも行わなければなりません。世界中で最高のドライバーと車とカーレースに挑むことになり、ドラッグレースの王冠

    GT Nitro: カーレーシング・ドラッグレーシングゲーム - Google Play のアプリ
    wtrmiya
    wtrmiya 2009/05/22
  • http://634.ayumu-baby.com/architecture/architecture_test.html

    wtrmiya
    wtrmiya 2009/05/22
  • 僕がTDDをやめた理由 - カタチづくり

    タイトルは、まあ、半分釣り。TDDな人もそうでない人も、肩の力を抜いてお気楽にどうぞ。 題に入る前に まずお礼 ここで書くことは、前の記事 TDDはYAGNIに矛盾する? - カタチづくり から派生して色んな方と意見を交わした経験が元になっています。この場を借りて、色々とアドバイスを頂いた方に心から感謝の意を表します。 特にコメント欄にお寄せいただいた きしだ さんのコメントは、コメントと言うよりももはや一つの素晴らしい記事となっていて、もう必読といってもいいレベルじゃないでしょうか。当にありがとうございます。特にBDDについて大きなヒントを頂きました。 押し付けではなく、交換 タイトルから想像がつくとおり、ここにはどうしてもTDDに対して否定的な意見ばかりが並んでしまう。でも、だからといって僕がTDDを完全に否定しているとは思わないで欲しい。 僕が今一番恐れていることは、TDDに対し

    僕がTDDをやめた理由 - カタチづくり
  • TDDはYAGNIに矛盾する? - カタチづくり

    Joel on Softwareに面白そうな記事が載っていた。 とはいえ、どうも僕の英語力では完全な読解が難しい。会話を書き起こしたものなので当然ながら文体が会話調で、僕にはなかなか理解が難しいのだ。以下で僕の読み間違いがあれば指摘して欲しい。 さて、冒頭で Joel 氏はこう言っている。 Joel: There's a debate over Test Driven Development... should you have unit tests for everything, that kind of stuff... a lot of people write to me, after reading The Joel Test, to say, "You should have a 13th thing on here: Unit Testing, 100% unit tests

    TDDはYAGNIに矛盾する? - カタチづくり
  • 第6回 テストケースの作成 | gihyo.jp

    前回は、TestLinkの基操作のうち、テストプロジェクト開始時に必要な操作について説明しました。続いて今回は、テストケースを作成していきます。 はじめに 図1にあるように実際にテストケースを作成していく、テスト設計・テスト実装という工程を対象とします。また、実際のテストプロセスではその前にテスト分析(仕様分析)という作業が必要となることも多いでしょう。 TestLinkは、あくまで管理のためのツールですので、分析・設計の作業はほかのツールを活用しておこなうことになります。これらの作業を省いて、テストケースの元となる仕様書などの資料(テストベース)から直接TestLinkにテストケースを入力していくことはあまりお勧めできません。あくまでテスト分析・テスト設計の結果をテストケースに落としていく時(テスト実装)の記述先がTestLinkになるということです。 テスト分析・設計の方法は、gih

    第6回 テストケースの作成 | gihyo.jp
  • Advanced Unit Test, Part V - Unit Test Patterns

    Previous articles in the series: Overview Core Implementation Testing Processes Fixture Setup/Teardown, Test Repetition, And Performance Tests What's New? Added a section on Presentation Layer Test Patterns. Join The Advanced Unit Testing Project! We're looking for experienced C# developers that can dedicate quality time to a large list of to-do features to help make Visual Test Studio the leader

  • 1