Contents unittest を効果的に使うための覚書 目的 ルール: テスト対象のモジュール(module-under-test)をテストモジュールに直接importしない ガイドライン: モジュールスコープでの依存を最小限にする ルール: 各テストメソッドでは、１つの事実だけを確認する ルール： テストメソッドは内容を表すようにしよう ガイドライン: setupはヘルパーメソッドで提供しよう。テストケースのselfで共有するのはやめよう。 ガイドライン: フィクスチャは可能な限り簡潔に ガイドライン： フックやレジストリなどの利用は注意深く ガイドライン: 依存関係を明確にするためにモックを利用する ルール: テストモジュール間でテキストを共有しない まとめ https://twitter.com/tokibito/status/412074246026698753 ということで
作りました。 動機となったtokibitoのエントリ まあロジックもそれほどないし、 bottle+peewee と比べてpyramidで書いたらどうなるかってので、１つ書いたのが こちら 。 オリジナルをほぼそのまま使いつつ、モデル定義を SQLAlchemy に変更。viewの関数の引数調整やURLの登録とかやって完成。 その後、調子に乗って、Zope2とPloneでもやってみた。 Zope2版 Plone版 Zope2版では、five.grokを使ってみた。 grokはZope Toolkitを使ったWebアプリケーションフレームワークで、規約ベースとなっています。 five.grokはこれをZope2上で使えるようにしたもの。 規約ベースなので、規約を知らないと、なぜこれだけで動くのかってのがわかりにくいはず。 app.py には Guestbookクラスが実装されていて、唯一のモ
最初に(Web)サービスを企画して、 マネージドサービスを使って省力化＆スケールアウトできるように構成したとして、 それがうまく効果を発揮して 「やってよかったね」 って思うことよりも、運用が始まって 「運用のコストを下げたい」 ってことの方が多いように思う。 最初から素朴な構成で始めた方がいいんじゃないか？ ローンチまでは夢が膨らむけど、運用になったら、 コストと収入がバ…続きを読む
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
