for i =

1から10までの足し算をするのに、下記のように書く。

sum = 0
for i in 1..10 do
  sum = sum + i
end
p sum

これをベーシックだったら、と考えると、こうなる。

sum = 0
for i = 1 to 10 do
 sum = sum + i
end
print sum

どこが違うかと見ると、for 〜 do は同じ。i = 1 to 10より、i in 1..10の方がわかりやすい、と言えばわかりやすい。
こんなことをつらつら考えているうちに、testに出会った。

# sumuptest
require 'test/unit'
require 'sumup'
class SumupTests < Test::Unit::TestCase
def testsum
  assert_equal(55, sumup(10))
end
def testsum2
  assert_equal(5050, sumup(100))
end
end

さっきのsum.rbとsumup.rbはつくりが違うので、なんともいえないが、なるほど、でしょ？
つまり、なんでもobjectということであるのですが、プログラム自体をこのテストに合格するようなつくりにしなければならない手間もあるけれど、その手間も可視化されているし、テストの中味も可視化されている。これならばバカでも出来る。
バカでもできる、というより自分でもできる。
いや、これで初めてできる世界ができた。と言おう。
すべてをこれに乗せていけば、世界は変わる。そんな感じとしよう。そこで一句。
ではなくて。

test化ルール。
１．なにかをしたいと思ったら、テストを考える。
２．ということはでき上がった姿をイメージする。
４．テストに通るように手順を考える。手順は手順だけでなく、プログラムの形も含む。

たとえば、中国語ができたい、と思ったら、
１．検定を通る
２．中国人と話せる
３．中国語の本を読む
というような考え方。そして、いままでだとそのために勉強する、というところだけけれど。
１．その前に検定テストをみる
２．中国人と話してみる
３．中国語の本を買ってみる
という方が先にくる。というような考え方。

ちなみにさっきのsumuptest.rbに通るようなsumup.rbは次のようになります。

# sumup.rb
def sumup(intt)
  sum = 0
for i in (1..intt) do
  sum += i
end
return sum
end

if $0 == __FILE__
  puts sumup(ARGV[0].to_i)
end