Kazuya Takeshima rummelonp

javascript におけるユニットテストについて (2013/01)

ここの所、数か月おきにjsのユニットテストってどうやるのが良いのか悩んでいる気がするので、一つ情報集約の為にメモ書きをしておきます。

何かちゃんと文章書いておけば、それに対する反応が集まって、オレサマハッピー的な展開を望んでいます。

単体テストというか、ユニットテストというか、そういうアレを書く為のフレームワークを探しています。
覚える事が少なくて強力なやつ。

機能テストというか、e2eテストいうか、そういうアレの事は別途考える必要がありますので、今回はスコープ外とします。

MessagePack for Ruby の新版をリリースしました！

すべてのコードをゼロから再設計し、 シリアライズの大幅な高速化 を達成しました。 ruby-serializers を使って過去のバージョン（v4）と比較したところ、Twitter, 画像, 整数列, 地理データ, 3Dモデルのすべてのデータセットで高速化しました。

ということで、ffマージはなぜ優れているかというと、マージ操作の際に機械的な構成変更が一切行われず、ブランチの移動が起こるのみなので、マージ後のブランチは、必ずあなたが入念にテストしただろうマージしたブランチと全く同じ構成であることが保証されるわけである。これが大きい。

衝突検知をくぐり抜けて機械的マージが構成を壊してしまう例は他をご参照いただくとして、no-ffマージの場合にそういう面倒に対応する手段として次のようなものがあると思うが、いずれも確実性でffマージには劣る：

ということで、どちらもffマージの恩恵を考えると、なかなか悩ましい。

転職してないけど祝いください

	<?php

	$screen_names = array(); // 検索したいスクリーンネームをarrayのかたちで入れてください
	for ($i=0 ; $i<10; $i++){
	$screen_names[] = "hogepiyo".$i;
	}

	$tas = new TwitterAccountSearch();
	$tas->Set($screen_names);
	$tas->Search();

	// ==UserScript==
	// @name ねえねえ今どんな気持ち？
	// @namespace http://udzura.jp/kokubun
	// @description 国分太一fier
	// @include https://www.facebook.com/*
	// @version 0.0.1.20121205
	// ==/UserScript==

	(function () {
	function pingTaichi () {

	#coding: utf-8

	module ActionView
	module Helpers
	module FormHelper
	def text_field_tag_for_date(object_name, method, options ={})
	# インスタンスの取得
	object = options[:object]
	original_value = object.send(method)