[Glass] Does Gemstone transform integration testing into unit testing?

Lyn Headley laheadle at gmail.com
Sat Jan 11 21:00:31 PST 2014

Hello Glass! I am still excited about Gemstone/S and I wanted to start a
conversation about testing.

It strikes me that a system based on Gemstone/S can be tested in a more
natural and seamless way than a system based on a "database." Have you ever
written tests that interact with a database? I have, and it is not as
smooth as writing tests for code based on the native data structures of a
programming language. You have to establish connections and submit queries
in ways that obscure the logic of the code you are trying to test.

Testing experts sometimes use the terms "unit testing" and "integration
testing" to refer to different kinds of testing. A "unit test" is a test of
a small piece of your system while an integration is something more
complicated, approaching the system as a whole. Here is what a poster on
stack overflow wrote.

"An integration test is done to demonstrate that different pieces of the
system work together. Integration tests cover whole applications, and they
require much more effort to put together. They usually require resources
like database instances and hardware to be allocated for them." [1]

Notice that for this poster a "unit test" is less likely to require a
"database" than an "integration test." But to my mind, Gemstone/S
undermines this distinction. In a typical Gemstone system, your application
is just Smalltalk objects in a huge and persistent memory. You don't do
anything special to persist them, you just create objects. So what does
this do to the notion of "integration testing" in such a system? Perhaps
with Gemstone, all testing is unit testing, or at least, perhaps it could

Lyn Headley

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gemtalksystems.com/mailman/private/glass/attachments/20140111/50266ddd/attachment.html>

More information about the Glass mailing list