These are exciting times in the mobile development space, especially for followers of RemObjects work. Whilst the likes of Xamarin and Embarcadero pursue their cross-platform abstractions, with varying degrees of success, RemObjects have been focussing on delivering genuinely native solutions and the long term vision that underpins their compiler architecture is proving itself in their ability to react Swiftly [sic] to the changing development landscape.
This is another one of those posts that has a bit of a double meaning in the same title. First, there is the matter of a useful hint/warning that I think could be emitted by a Pascal compiler. The other is what I have been up to in recent months that I have been so busy that I wasn’t posting much (i.e. at all) !
First the more relevant point to this blog:
When you say nothing at all, in Pascal
For a while now I had been frustrated by Visual Studio‘s sudden decision to be un-cooperative when saving new projects, but have finally solved the problem! Or at least, that manifestation of the problem that was afflicting me.
Read the rest of this entry »
A post came up in recent days on the NZ DUG mailing list, about a problem with the LoadXMLData() function on Android. The problem subsequently was found to also exist on Win32. And indeed, the cause was found to go back at least as far as Delphi 2006. So why did it only come up now ?
Over the past few weeks there has been some speculation as to what the mysterious “Hydrogene” that RemObjects have been working on may or may not be. Well, that particular feline has slipped it’s captors and escaped the bag.
To address some odd concerns about differences between DUnit and Smoketest, I thought it would be useful to demonstrate how it is entirely within the gift of a Smoketest user to create their own “comfort” layer, to make using Smoketest more similar to the DUnit framework if they wish (though why in that case they wouldn’t simply use DUnit, I can’t quite fathom. But still).
This post is a peek behind the curtain of the next major update to Smoketest which I hope to have completed shortly: Performance Case visualisations.
A couple of commenters on my previous post have taken issue with my use of interfaces to form contracts between test cases and the test framework, rather than using simple virtual methods and inheritance as found in DUnit. I thought it would be interesting to illustrate why I went down this route.
In a previous post I demonstrated how the default “pretty name” for a Smoketest test case (derived from the test case classname) can be over-ridden by a test developer by implementing a specific interface (INameCase) on the test case class itself. There are some other interfaces that can be implemented on a test case, including interfaces that allow a test case to implement housekeeping tasks for the tests it provides.
Writing tests in Smoketest is intended to enable a test developer to write tests in a way that describe themselves, without requiring the test developer to add this “narrative” themselves. To see this in action, I thought I would compare some simple DUnit tests with the equivalent using the Smoketest framework.