APIを利用した、オープンソースのシステムトレードフレームワークです。・自分だけの取引アルゴリズムで、誰でも、いますぐ、かんたんに、自動取引を開始できます。この広告は、90日以上更新していないブログに表示しています。雑記うちのチームのテスト事情について、反省を含めてまとめてみます。その前に業務内容などいわゆるビジネスロジックを作ってます。サーバーモジュールとそのクライアントモジュールを開発している。サーバーモジュールはさらにDAO的なモノに依存している。クライアントモジュールはライブラリのみ。UIは別のチームが開発。テスト事情やっていること結合テストクライアントのAPIを叩いて、クライアント-サーバー-DBの結合動作をテストする。工数を割いて網羅的に実施。クライアントから実行して試すのが難しい操作(処理の途中でDBが落ちた場合とか)はテストに含めていない。この辺は、モックを利用した単体テストで補完する必要があると思う。単体テストクラスごとの単体テスト。独立性が高く結合度の低いクラスについては行なっている。DAOを使うクラス(ロジックとか)は、単体テストはしていない。(結合テストでカバーする、という考え)。本来はDAOのモックを用意してテストするべきなんだろうけど、それだけの工数はとれていない。性能テスト十分なパフォーマンスがあるかのテスト。使われる操作についてのみ。網羅的には行なっていない負荷テスト多重度を上げてもちゃんと動くかのテスト。使われる操作についてのみ。網羅的には行なっていないやってないことUIからの結合テストUIチーム任せ。受け入れテストリリースされた依存モジュールがこちらの要求する仕様を満たしているかどうかのテスト。DAOなんかは他のチームが作成しているモジュールだけど、受け入れテストは特に用意していない。チームは違うけど同じ部署だし、そこまで信用してなくはないです、といったところ。別の部署や外注したモジュールとかなら必要だろうな、とは思う。テストカバレッジ100%とか目指して、geter,seterのテストとかいちいち書いたりする暇はありません。いって90%とか謎の数字を導入するのもアレだし。有意義なテストに注力すべきと思う。網羅性の目安としては使えると思うんだけどね。「必ずXX%達成!」といった規約にはなっていません。テストファーストやってないなー。実装で事故があっても最低限モノはできているように、先に実装して残った時間でテストするという流れになってしまっている。スケジュールをずらしても最低限結合テストは書くようにしてます。思うところ結合テストは作成しているけど、網羅性は低いなとは思う。この辺は単体テストでカバーすべきと思うけど、コスト的になかなか厳しい。「1クラス1テスト」とか夢のまた夢。ロジックのテストとか、いちいちモックとか作ってられんて。JMockとかユーティリティはあるにしても、依存ジュールの動作をエミュレートするのはなにげに大変だし。結合テストを補完する目的に沿って、ポイントを押さえた単体テストを充実させていく、というのが現実路線かと。性能テストや負荷テストはもうちょっと網羅的にやるべきだと思う。性能計測とか、なんだかんだで繰り返し測る場合が多いし。このへん、開発担当者本人じゃなくて別のチームの人とかアルバイトさんがやってる、とかいう事情はあるんだけど。あと、すべての結合テストの実行に2,3時間かかるのはそろそろ何とかしないと。»プロフィールid:unageanu今日学んだことを、ちょろちょろ書いていきます。(1)はてなブログをはじめよう!unageanuさんは、はてなブログを使っています。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。