# Runtime Checks Testing

**URL:** <https://www.ruby-forum.com/t/runtime-checks-testing/170292>\
**Category:** Ruby\
**Created:** [June 15, 2009, 4:48pm UTC](https://www.ruby-forum.com/t/runtime-checks-testing/170292 "2009-06-15T16:48:33Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![tcsnide](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/t/eb8c5e/32.png) [@tcsnide](https://www.ruby-forum.com/u/tcsnide)\
**Post date:** [June 15, 2009, 4:48pm UTC](https://www.ruby-forum.com/t/runtime-checks-testing/170292/1 "2009-06-15T16:48:33Z")

</div>

While expanding on unit tests for a project, I started to wonder if a  
“pre-unit testing” system made any sense --basically a dynamic runtime  
checks system. The idea is that for every class, you create a runtime  
check subclass, in which methods provide real-time conditions. Then  
there would be some mode switch that would automatically use the check  
classes vs the regular ones. Eg.

class MyClass  
def exclaim(y)  
y + “!”  
end  
end

class MyClass::Check \< MyClass  
def exclaim(y)  
result = super  
raise SystemCheckError unless result == “#{y}!”  
result  
end  
end

Now obviously this is a very stupid example, but it presents the basic  
idea. This is sort of like double entry book keeping. We are creating  
some real-time checks to ensure things are running along as we expect  
them too.

What do others think of this sort of thing? How might a system like  
this effect unit testing? Could it replace it? Or help reduce the  
extent that unit tests are needed? Or simply compliment them? Or is  
this a worthless notion all together?

One thing I notice, it has some upside in encouraging good coding by  
encouraging small methods.

T.