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人から始める社内テストコード文化
# -*- coding: utf-8 -*- from __future__ import absolute_import, unicode_literals # テストする関数 def add(a, b): return a + b # テストコード 関数名はtest_ から始めるのがpytestでのお作法 def test_add(): assert add(1, 1) == 2 assert add(1, 2) != 2 >>> $ py.test ../tests/test_add.py =============================================================================== test session starts ================================================
テストコードとか書いてみてもいいんじゃない？ - Qiita
from dog_bark import dog_bark def test_dog_bark(): assert u'ワンワン！' == dog_bark('Japan') assert u'Bow wow！' == dog_bark('USA') となります。 実際にdog_bark関数を実行して、想定した結果文字列と直接比較するというコードです。 世に言うテストコード書こうぜ！という主張はこんな感じのコードを量産しようぜ！ ということになります。特に難しいことはないですね。 テスト実行は例えばPythonのPytestなら $ py.test test_dog_bark.py でOKです。もしテスト関数を増やしたとしても勝手にファイル内のテストを認識して 実行してくれます。 ちなみにどの言語のどのテストフレームワークもこのくらいの機能はあります。 (コンパイルがいる言語は多少手間が増
Bash用ユニットテストフレームワーク作りました - Folioscope
Bash用テストフレームワークに、Batsやshunit2がありますが、イケてないなーと思ってたら、気づいたら自分で作ってました。 github.com テストの結果はモダンなテストフレームワークのように、カラフルに表示します。 またFAIL時は、FAILしたテストの結果を表示します。 自分の Arch Linux 上の Bash 4.3.42 および、Travis CI 上で動作することを確認しています。 インストール curl -o ~/bin/bashtub https://raw.githubusercontent.com/ueokande/bashtub/v0.1/bin/bashtub chmod +x ~/bin/bashtub です。ただし~/binはパスが通ってるとします。 これでターミナルから bashtub と打つことで実行できます。 bashtub テストを書く 各
OSS についてあれこれ
unassert - encourage reliable programming by writing assertions in productionTakuto Wada
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ページを開く
Edge Components 概念、計画とインストール / WebSphere Application Server
Bug #1205583 “nautilus crashed with SIGABRT in __GI___assert_fai...” : Bugs : nautilus package : Ubuntu