DB設計のカタログサイト。新しくテーブル設計する際には必ず一度ここを見る。見た目は古臭いけど数と質が圧倒的 / Industry Data Models https://t.co/5FPA7fmpyx
Takuto Wada on Twitter: "DB設計のカタログサイト。新しくテーブル設計する際には必ず一度ここを見る。見た目は古臭いけど数と質が圧倒的 / Industry Data Models https://t.co/5FPA7fmpyx"
DB設計のカタログサイト。新しくテーブル設計する際には必ず一度ここを見る。見た目は古臭いけど数と質が圧倒的 / Industry Data Models https://t.co/5FPA7fmpyx
Facebook製のJavaScriptテストツール「Jest」の逆引き使用例 - Qiita
はじめに みなさん、日頃JavaScriptのテストはどのように行っていますか？ 昨今ではAngularJSやReactJSを始め、JavaScriptのフレームワークやライブラリを使用してのフロントエンドの開発が当たり前のようになってきております。 ではそのフロントエンド、JavaScriptのテストはどんなツールを使っていますか？ mochaやpower-assert、chai、Karma、Jasmine等を組み合わせて使用してテストしているでしょうか。 前置きが少し長くなりましたが、Facebookが開発したオールインワンな「Jest」というツールのReactでのHowto的な使い方から実際のテストでの使用例を交えて紹介したいと思います。 ちなみにこのJest、最近リリースされて話題になったパッケージ管理のYarnでも使われています。 対象バージョン Jest:22.0.4 Reac
たった1人から始める社内テストコード文化
>>> $ py.test ../tests/test_webapi.py =============================================================================== test session starts =============================================================================== platform darwin -- Python 2.7.5 -- py-1.4.31 -- pytest-2.7.0 rootdir: /Users/*****, inifile: pytest.ini plugins: cache, django, pep8, pythonpath collected 2 items ../tests/test_webap
テストコードとか書いてみてもいいんじゃない？ - Qiita
本記事はテストコードを「書いたことない」、「いらない」、「意義がわからない」 といった方々に、「書いたらちょっとはいいとこあるよ」と紹介する記事です。 そもそも書き方がわからない ※バリバリテスト書いてる人は飛ばしてください テストコードの書き方って習ったことありますか？ そういえばないなーなんか難しいことやるんでしょ？ って方もそれなりの数いるような気がします。 まず結論から言えば、テストコードは基本的に、 割と泥臭いよ！ なんか自動的にソースファイル内の関数引っ張ってきてくれて、 値評価とかもしてくれる。でも難しいんでしょ？ と思ってたりする人もいるんじゃないでしょうか。 そう思っていた時期もありました。 (探せばあると思いますがたぶんお金かかる系。むしろお金取れる系) 簡単に例を挙げますと、 犬の鳴き声を国を指定して取得する関数
OSS についてあれこれ
unassert - encourage reliable programming by writing assertions in production
Junitでjavaの単体テストを作る - うめすこんぶ
javaのテストフレームワークであるjunit．使い方を少し学んだので書いておきます． eclipse (Kepler)ですと，標準で入っているので手間が無いですね． eclipseでのjunitの使い方 パッケージエクスプローラの中で，テストを行いたいクラスの書かれたソースをクリックして選択 右クリックで新規→その他 java→junit→junitテストケースを選択→次へ そのまま次へ テスト・メソッドの画面になる．使用可能なメソッドからテストを作りたいメソッドをチェックして完了 junit4がない問われたらOKで． 結果，テスト用のクラスが作られる． テストで使うクラス 今回テストするクラス： public class JunitExample { public JunitExample() { // TODO 自動生成されたコンストラクター・スタブ } public int foo
最近のC++17事情
C++1z、あるいはC++17とも呼ばれている次のC++規格の、最近の事情はどうなっているのか。すでにドラフトに取り入れられた機能もあるので、現在の最新の状況を見ていこう。もうすでに紹介したものも含まれているが、おさらいとしてみていく。また、ここで解説する新機能は、いずれもすでにドラフト入りしているが、正式に規格制定される際に変わる可能性がある。 N3928: メッセージなしstatic_assert C++11で入ったstatic_assertは、必ず文字列リテラルを書かなければならなかった。 static_assert( INT_MAX >= 2147483647, "This code assumes at least 32-bit int." ) ; static_assert( true == true, "You're compiler is fundamentally wro
初めから厳密すぎるテストを書くのは筋悪なのではないかという話 - 愛と勇気と缶ビール
これは人それぞれのコードの書き方に依存するので必ずしも筋悪というわけではない。むしろそういう風に書いてしまえる人もいるだろう、くらいの話。 何が言いたいかというと、自分の場合、ある程度は頭の中でまとめつつとりあえず手を動かして書いてみる→気に入らなかったり、後から「これではあかん」と思ったらインタフェース変える、みたいなことを繰り返しながら、要は同時にリファクタリングしながらコードを書いていくので、初めから厳密すぎるテストを書いてしまうと手戻りが多くなって非効率的なのである。 例えば、とあるJavaScriptのメソッドの返り値がこんな感じだったとしねえ。 { valid: true, foo: 10, bar: 0 } で、"valid"の部分はほぼ間違いなくこれで行くけど、"foo"と"bar"の部分は後から無くすかもしれない。あるいはkey名を変えるかもしれない。あるいは何か別のke
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
