You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert
「Web API のすすめ」は割と概念的な話に終始していて、コードベースのもっとゴリっとした話を期待していた人には申し訳ありませんでした。 が、やはり既存の WAF を使っているだけだとわからないことっていうのが多いと思うので、もっと下のレイヤーに降りて、自分で実装するのもありなんじゃないのかなって思っています。 「let's database testing」では、割と見落とされがちなんじゃないかという、DB のテスト方法についてざっくばらんに話しました。ちょっと本質的でないことも書いてありますが、重要なのは、「実際に運用される環境に*なるべく*近い環境で、ローカルでテストをする」ってことです。DB テストのほんの足がかりになれば幸いです。 BD テストの話で使ったサンプルのリポジトリは以下になっています。 xaicron's Mayoi at master - GitHub 結構中途半
めも FGはdefineの仮引数周りが無駄 (blueprintで改善) FGはinstanceをフラットに管理しすぎ FGのsequence(next)はイケてる FGはAR前提 Machinistは定義がイケてるが、名前がダサイ(make_unsaved) Machinistはメソッド名が衝突しそう(makeはアカン) Machinistはinstanceをクラス毎に分類できるが、Shamレベルまで落ちるとフラットになる片手落ち感 Daddyの使えなさは異常 FGの継承はどうやるの？(-> :parent) FG.blueprint は :parent を理解してくれない 試行錯誤 Factory.sequence :login do |i| "login#{i}" end Factory.define(:user) do |user| user.login {Factory.next
Rails のテストを書いていて、フィクスチャはのちのちメンテナンスに苦労しそうだから FactoryGirl を使ってみた。 FactoryGirl についてはここが詳しい http://www.func09.com/wordpress/archives/532 上のページの例にあるとおり、中間テーブルを使うようなケースでテストデータを定義するのに便利らしい (公式ページ?でもそのように宣伝していた) のだが、中間テーブルが不要な has_many/belongs_to の関係を定義するときに、 association を親子どちらに書くかでハマってしまった。 すぐ動かせるコード例がなくて恐縮だけど、 FactoryGirl で has_many/belongs_to な association を定義するときは、必ず子のほうに親の Factory を書かないといけないっぽい。このスレッ
Libraries » thoughtbot/factory_girl (main) » Index » File: README factory_bot factory_bot is a fixtures replacement with a straightforward definition syntax, support for multiple build strategies (saved instances, unsaved instances, attribute hashes, and stubbed objects), and support for multiple factories for the same class (user, admin_user, and so on), including factory inheritance. If you want
フィクスチャのメンテナンスが大変で、何かないかなって探してて見つけた。 django-autofixture 0.12.1 : Python Package Index Djangoのモデルのメタ情報からフィクスチャデータを適当に作ってくれたりする。 Railsだとfactory_girlみたいなもの。 こんな感じで書ける。 from django.db import models from django.test import TestCase from autofixture.base import AutoFixture class MyModel(models.Model): name = models.CharField(max_length=20) class MyTestCase(TestCase): def test_create(self): filler = AutoF
Java Ruby on Railsのfixtureという機能は有名なので皆さんご存じかと思います。JavaでいうJUnitのTestCaseクラスに、 fixture :test と書くだけでtestというテーブルにtest.ymlという名前で用意されたテストデータが投入されるという機能です。 同じような機能はJavaでもかなり以前からDbUnitとして提供されてきましたが、使い勝手という点で圧倒的にfixtureが勝っている。というのは、DbUnitは汎用的なライブラリなので使うためにはDBへの接続定義をコードで書いたり、ロードするxmlファイルを探したり、といろんな手間があったのです。 DbUnitはデータベーステストのデファクト・スタンダードなのでJavaプログラマなら一度くらいは使ったことがあるかと思います。私も仕事柄いろんなところのアプリケーション開発環境を構築するのを手伝いま
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
