STON for VAST on VASTGoodies

I’ve just uploaded a port of STON, the Smalltalk Object Notation for VA Smalltalk to the VASTGoodies.com repository.

STON is a project that was implemented by Sven van Caekenberghe on Pharo Smalltalk and it is a slightly extended version of JSON (Javascript Object Notation) to persist Smalltalk objects in a human and machine readable form. JSON is a bit of a successor for XML in many areas, because it holds some of the promises that XML never could. In fact, the format itself is language independent, so you could also export and import objects from most other object oriented language. STON can also read and write pure JSON data.

The code is quite compact and well-done. I had to change a few things, mostly in the tests, due to language constructs that are supported in Pharo Smalltalk but not in VAST.

What can STON be used for? The options are numerous, but there are a few highlights I’d like to mention and that I found it promising for:

• Use it as as simple persistence mechanism to save objects (like XML, but easier to edit)
• Exchange data between two Smalltalk dialects or Smalltalk and any other language that speaks JSON/STON
• Send JSON data to a JavaScript application that runs in a web browser
• Exchange Smalltalk objects with a web application implemented in Amber.js
• you can surely think of others…

STON is extremely simple to use and performance is not too bad for reasonable amounts of objects. More details about STON can be found on its github page.

So I’d be interested in hearing if STON is being used in the VA ST world and of course also about bugs and possible extensions.

STON also is the basis of Cypress, which is intended to make version control of Smalltalk code in “normal” source control systems like git or mercurial simpler. Who knows, maybe cypress one day even allows for exchange of smalltalk source code between smalltalk platforms with at least some level of automatic code conversion.

Seaside 3.0.7 (partially) and jQueryMobile 1.1.1 ported to VA Smalltalk

Marten’s been busy over the last few days and just released a new version of a partial Seaside 3.0.7 port (Instantiations ships VA 8.5.2 with Seaside 3.0.6), which he needed for the latest bels and whistles of Nick Ager’s Seaside integration for jQueryMobile V 1.1.1, which he also ported and released on VASTGoodies.

From the package comments of Marten’s Seaside version:

V 8.5.1 - with FileLibrary Addition from Seaside 3.0.7
  -> Caution: Not an official version. Use on your own risk.
  -> version needed for JQM 1.1.1 development  (Marten Feldtmann)

So it is not actually a full port of Seaside to VA ST 8.5.2, but the File Library additions that are important for jQM (I guess that means virtual file libraries).

VA Smalltalk 8.5.2

Instantiations has just released VA Smalltalk Version 8.5.2. As the version number indicates, this is more or less a maintenanc release with a number of bug fixes and enhancements.

But there are also new features in this version, the most important from my perspective are:

• Code Assistance now available in Inspectors:
  The addition of Code Assist was a productivity booster for me. I got so used to this little friend that going back to older versions of VAST felt somewhat awkward. I was constantly waiting for the suggestions to pop up. Getting available variables and methods in the Inspector makes life even easier now.
• Monticello Importer added
  This could be the beginning of a little wave of new open source contributions to VASTGoodies.com. Now that it’s become a little easier to load Smalltalk code from Monticello repositories, at least the lowest hurdle for porting code from Squeak/Pharo to VA Smalltalk is gone. Instantiations made the Monticello Importer available as a beta/preview feature some months ago, but now it is part of the product. If you wonder what the process of porting code to VAST using the Monticello Importer, you could go back to this post of yours sincerely and start porting code from squeaksource or, better, squeaksource3, right away, thus making our lives with VA ST a little more fun.
  I really hope Instantiations will also consider building a tool for the opposite way: we need to move closer to the rest of the Smalltalk world and we need the ability to contribute fixes to open source projects and should also be able to release VAST goodies for other dialects. You may not have realized yet, but there are quite a few nice goodies coming from the VA Smalltalk community that might be of interest to Squeakers or Pharoers.
• Support for Time zones introduced
  Oh, the joys of handling Dates, Times, Daylight Saving Time and Time differences. What else should I say?
• System>>#getProcessId added to retrieve the pid of the running process
  This one goes back to a question I asked on the VA Smalltalk support group. It can be very handy to know the PID of a running Smalltalk image, especially on a web server that needs to take control over what images are running and/or need to be stopped or restarted.
• GLORP updated to version 0.4.190
  Unfortunately, I have no idea what this version number means. To my knowledge, Glorp has the versioning scheme of the VisualWorks version it ships with. So this might still be some quite old Glorp version. I had to fix a number of issues in the Glorp version that shipped with VA Smalltalk over the last few months, but still I find Glorp to be a very powerful and nice framework, even though I sometimes find the code hard to understand (so I still have unresolved issues due to my inability to fix them). But it is good to see that Instantiations is updating Glorp and thus offers a current and powerful relational database framework for VA Smalltalk. Glorp sure is the current gold standard here in the Smalltalk world, since it is now supported on all major ST dialects

Where to get it?

VA Smalltalk 8.5.2 is available immediately and can be downloaded from Instantiations’ website. If you are a registered and/or paying user, you can simply download it using your registration details. If you’d like to purchase licences, you can either contact Instantiations or one of their resellers ( as it happens, my company is a reseller for Germany, Austria, Switzerland and Benelux countries) for more details.

Use VA Smalltalk for free?

Did you know VA Smalltalk is free to use for personal / evaluation purposes? Simply register with Instantiations for download credentials. Instantiations also gives away licences with email support for educational institutions and for open source committers. Visit their website for more details.

MiniSMock 0.3 uploaded to VASTGoodies

I finally found the time to upload the latest version (0.3) of MiniSMock to VASTGoodies.com. I would love to get feedback on it, so please let me know if it’s useful for you, if you find some bug or are missing some important feature.

MiniSMock is just learning a few new tricks

MiniSMock is my minimalistic approach to Mock objects, which can be extremely helpful in testing legacy code as well as code that has a lot of dependencies and is hard to set up.

I wanted something that is extremely lightweight and fits well with SUnit, witout any complex setup rules or other hassle. There are much better and more complete Mock Object frameworks out there, but for my needs the most important requirement was that it’s simple enough to use right away. There really isn’t much to it, not even something that you could call documentation, since it is just one single class. If you want to take a look, feel free to download it from VASTGoodies and use it. Let me know if you find something that is missing.

Reflecting MockObjects – A new kind of intelligence?

Somebody just did exactly that and asked me if they could possible use it in their code base which is quite defensive and uses a lot of reflection to test whether an object is ready

Download-Statistik des Smalltalk Inspect Podcast

Marten hat auf seinem Blog die Downloadzahlen unserer immerhin schon 14 Folgen des Smalltalk Inspect Podcasts veröffentlicht:

Datum    Hörer #   Titel
17.02.11 0189  001 "Einführung"
13.03.11 0120  002 VASmalltalk - Teil 01 GUI
20.03.11 0116  003 VASmalltalk - Teil 02 ENVY
17.04.11 0096  004 VASmalltalk - Teil 03
24.04.11 0097  005 Smalltalk Solutions, 01
01.05.11 0112  006 Smalltalk Solutions, 02
22.05.11 0184  007 Prof. Brauer: ObjectsFirst - Smalltalk in der Hochschulausbildung
24.07.11 0202  008 Thomas Holzer, HRWorks: Smalltalk auf Wolke 7
16.08.11 0209  009 Claus Gittiger, eXept: Smalltalk aus Deutschland
14.11.11 0106  010 Norbert Hartl über vmware GemStone/S
27.11.11 0080  011 Christian Haider, Smalltalked Visuals: Smalltalk in den Charts
14.12.11 0066  012 Thomas Koschate and Continuous Integration in VA Smalltalk
15.01.12 0076  013 Esther Mietzsch vom Squeak e.V.
02.02.12 0081  014 Adriaan van Os, DeltaLloyd, on VASTGoodies

Wenn man bedenkt, dass wir mit Smalltalk Inspect eine so genannte Nischensprache abdecken, und uns sogar fast komplett auf die deutsche Sprache konzentrieren,

Smalltalk Inspect Episode 14: Adriaan van Os on VAStGoodies and Smalltalk in the Netherlands

In our latest episode of the Smalltalk Inspect we not only practice our english but also talk to Adriaan van Os from the Netherlands. Adriaan is known for his photo coverage of all major Smalltalk events during the past years, but more importantly as one of the main contributors to the VAStGoodies server, the primary place to share open source code for VA Smalltalk.

He tells us about his work on VAStGoodies.com and the use of Seaside and Smalltalk at Delta Lloyd (the company that sponsors the server infrastructure of VAStGoodies), one of the biggest insurance companies in the world. Besides that we talk about the Smalltalk community in the Netherlands and the “Back to the Future” initiative which works on making Smalltalk better known in other dynamic language communities and will be presenting at the Smalltalk devroom this coming Sunday at the FOSDEM conference in Brussels, Belgium.

You can download this and every other episode from the Smalltalk Inspect homepage. Smalltalk inspect is also available on iTunes.

Yet another Mock Object “framework” for VA Smalltalk

I’m currently preparing a training/workshop for a new customer where we want to find ways and techniques to improve their use of unit tests in a legacy Smalltalk project. They’ve been using VA Smalltalk for a couple of years successfully and provide a very respected family of products in their field. In fact, they say they are a market leader in the very business. After a few years of trying to ignore the fact they successfully use Smalltalk in their product, they’ve come back to a point where they accept it as a useful technology that has its place and benefits – even if it is not considered mainstream.

So they – like many other Smalltalk projects – are faced with the fact that they missed the train for unit tests and code improvements in their Smalltalk pool while most other teams adopted these techniques years ago. So now they need to find a way to get their product under test without breaking it. Not that this can’t be done, it’s just a question of where to start and how to get all team members into the same boat while accepting that there is no chance to get a significant percentage of test coverage any time soon.

But back to what I wanted to write about. I am going through notes and code snippets of projects I’ve worked on to find useful stuff that we can use as starting points or discussion base for their specific way to test land. I stumbled upon a little Mock Object implementation that I had implemented back when I was young, so much younger than today… (wait, isn’t that some line from an old Beatles song, that’s even older than that?).

It simply consists of one class that can be configured to answer messages with defined results and interview it how it went after it was used. The whole thing was inspired by an old blog post by Sean Malloy and is really a neat, tiny and feature-poor simplest thing that could possibly work. Nevertheless, I couldn’t find a ready-made Mock Object implementation for VAST on G, so I thought it probably won’t hurt if I uploaded mine.

So there it is on VASTGoodies, ready for you to explore, use, extend and post a better version back to VASTGoodies. Feel free to like it or port another one to VA ST, there are several better ones available for VisualWorks, Squeak and maybe more.

There really isn’t much to say about the tool, other than that it’s easy to setup and use, you can always take a loot at the TestCase in the MiniSMockTests Application that comes with MiniSMock.

Here’s a mini-tutorial for MiniSMock:

You set up a Mock Object like this:

mock := MockObject new.
mock answer: #test with: [Date today].
mock answer: #sayHelloTo: 
  with: [:aPerson| Transcript show: 'Hello, ', aPerson asString;
    cr. aPerson].
mock answer: #sayHelloTo:and:
with: [:aPerson1 :aPerson2| Transcript show: 'Hello, ',
   aPerson1 asString, ' and ', aPerson2 asString; cr. aPerson2].

and you can then send messages to it. Just like this:

mock sayHelloTo: 'Joachim'.

In a Testcase you can then ask a MockObjects a few questions:

mock receivedMessage: #sayHelloTo:.
mock receivedMessage: #sayHelloTo: withArguments: #('Joachim').

And that’s all folks.
But don’t underestimate the power of Mock Objects when it comes to introducing unit tests in a legacy project!

SUnit extension uploaded to VASTGoodies.com

I’ve just uploaded my little extension to the SUnit Framework to VASTGoodies. If you’d like to try it, I suggest loading the map z.ST: SUnit Testing.

What does it do?

It simply keeps the text that were defined in test assertions like assert:description: stored in an individual TestCase when the test fails, or the name of an exception thrown when a TestCase ended in an error. This is achieved with an additional instance variable in TestCase and a tiny change to TestCase>>performTest.

What is that good for?

One thing that I’ve been doing for quite a while now was helping Smalltalk Legacy projects to get back to the speed and agility that Smalltalk enables, but these projects never reached due to their corporate state of being legacy and about to be switched off any time soon now. Knowledge and Motivation was lost to other projects and therefor the code quality and project techniques are sometimes in a very sad state.
The most unwanted job in such project teams is the packager’s and code manager’s, because it takes a lot of time and is a mine field  in most projects: rotten code structures, undocumented procedures for packaging and deployment preparation and lack of knowledge, because the guy who used to do it left the team some years ago and never kept records of what to do and why.
In comes continuous integration and tools like hudson/jenkins that are excellent in performing automatic tasks like running tests, packaging, preparing a deployment directory and such.

A big shortcoming of SUnit in combination with hudson is that it doesn’t keep the description texts of assumptions anywhere. You can only see them if you debug a TestCase in the Test Browser or a workspace snippet, and only if you run that very test individually. Running a big TestSuite means losing these texts completely.
This is especially bad in combination with a tool that can keep a list of all failed tests for statistical reasons and more importantly for all team members to check every morning. It’s really annoying if you have to rerun a single t

So I wanted to add the descriptive Text to some kind of list that I can use to provide useful feedback.

So what is different now with failureTexts?

You can now run a TestSuite and inspect the TestResult. TestResult keeps a list of passes, failures and errors, which are the TestCases themselves (an instance of TestCase with the name of the individual test method it ran in the variable testSelector). Now a TestCase has an additional variable named failureText which holds a descriptive text of what failed or error’d (If you used assert:description:).

So if you write an assertion like

self assert: (1+1=3) description: ‘Smalltalk knows that 1+1 is not 3′.

You will find the TestCase in the failures list of the TestResult, and its failureText variable will contain the text ’Smalltalk knows that 1+1 is not 3′.

That’s all folks. A little change that can help a lot!

What does it help?

In our projects we have a little exporter tool for SUnit test result in a jUnit compatible XML file. This can be imported by hudson and kept as one of many statistics of a build. So now we have a list of test results that each team member can browse each morning and see if their tests failed and what exactly failed in it.

Can I use it in my dialect?

I haven’t tried yet, but the code change is very small and I suspect it is completely portable. One of the tests in SUnit Testing references an exception class by name (ZeroDivide) and that may have to change in other dialects, but other than that I see no reason why it shouldn’t be portable. I’m happy to provide file out instead of a .dat to anybody who’d like to try the change in their favorite smalltalk. I’d also be happy to hear from you if you tried it and what you think of it.

Little Addition to SUnit: keep a failure text with errors and failures

I’ve posted about a problem I’m having with SUnit before: a TestResult does not hold the description Strings of failures and errors, so it is not easy to log unit test results with bare SUnit.

I need this for our Hudson Build Server integration on our project. While some developers have solved this problem by using their own Test runner implementation that writes a log file in jUnit Format right during the run of a TestSuite, I’d prefer to first run the tests and harvest all the Results from the TestResult afterwards. It may be a mere question of Taste but I think mixing test running code with XML generation has a certain smell.

For quite a while we simply ignored the problem and fed an XML file back to hudson which contained the text “The test failed – please rerun it in the SUnit Browser for details”. Which is of course exactly what you have to do when you want to fix that test or the code it tests: rerun it in the Test Browser and maybe debug or step it to see what’s wrong. But it felt strange. We had spent so much effort into automated build tools and hudson integration batch files and stuff just to see a bloody placeholder text in our statistics. It just feels like being a whining coward, not a redneck programmer. But what’s even worse is that the developers tend to not add descriptions to their assertions, because they’re useless anyways. So this little glitch in SUnit may lead to tests that tend to be cryptic. Part of my consulting job is to convince long-time Smalltalkers about the usefulness of unit testing in legacy projects. There’s not much that’s more depressing than to see how people finally use unit tests and suddenly realize they give up on descriptive assertions for that reason.

So there’s always been the idea of “fixing” SUnit to make it keep the description Strings for failed assertions. It turned out that it’s neither easy nor elegant, at least none of the ideas I tried.

The best and most natural place for an extension first seemed to be TestResult>>#sunitAnnounce:toResult:  which was introduced in SUnit 4. Here’s what the release notes for SUnit 4  say:

TestResult now double-dispatches via the exception (see #sunitAnnounce:toResult:). This makes it easier for users to plugin specific behaviour.

Unfortunately, there are two problems with this method:

1. The exception thrown or failed assertion is not handed over to this method, so you can’t store it anywhere
2. If you simply create and instance of a TestCase and send it #runCase to run it, there is no TestResult involved in running it

Another problem is that even if we mostly run our tests in the form of a TestSuite which always produces a TestResult, the collections #failures and #errors do not store some kind of test result object, but simply the TestCase instance that failed/error’d.

So the simplest thing that could possibly work is to add an instance variable to TestCase to hold a String (well, it can of course hold anything, we’re using Smalltalk after all). This variable would be set to an empty String just before a test is run and be filled with either an exception’s description if test execution results in an error, or with the description text of a failed assertion.

This gives us the ability to not change much about the way TestResult works, not break the SUnit Browser or any other SUnit-related tool, but keep the error texts.

It turns out this worked quite well for our project, and there was very little I needed to change in SUnit:

1. Add an instance variable #failureDescription to TestAsserter (with getter/setter)
2. Change TestCase performTest to:

   performTest
     "Implemented and tested on VA Smalltalk 8.5, but should be portable"
       [
         self failureDescription: ''.
         self perform: testSelector sunitAsSymbol]
           sunitOn: TestResult failure , TestResult error
           do: [:ex |
               self failureDescription: ex description.
               ex pass]

And that’s it. I can now iterate over the #failures or #errors of a TestResult and harvest their decriptions to do whatever I want with them. In my case I want to add them as XML tags into our jUnit-xml for the hudson server. So far we’ve not had any problems with this change.

I’m well aware that this is neither an extraordinarily clever nor galactically elegant solution, especially since it involves changes to the SUnit code base. But I like the effects I see so far. The feedback from the team is: “I can now tell right from the hudson log what my bug is in many cases”.

Before I am putting this change up to VASTGoodies.com, I’d like to hear what other people think about this change. Is it going in the wrong direction? Too invasive into the concepts of SUnit? Would people rather put this kind of thing into the logging portion of SUnit (Be aware that logFailure* methods are only executed for failures, not errors!) or do they like this approach? Any better ideas out there? How did you solve this problem?