Summary:
This article describes Borachio, a mock object library for Scala. Unlike the popular Java mock object libraries, Borachio does not require cglib and can therefore be used to test Android applications. In addition, unlike its Java cousins, Borachio supports both mock objects and mock functions.
The ability to add new comments in this discussion is temporarily disabled.
Most recent reply: January 6, 2014 8:09 PM by
lluulnw
|
Paul Butcher discusses Borachio. Read this Artima.com article: http://www.artima.com/scalazine/articles/borachio_mock_objects_for_scala.htmlWhat do you think of Borachio?
|
|
|
For information on what's coming up in Borachio 2.0 (including mocking static methods and "new"), see: http://www.paulbutcher.com/2011/07/power-mocking-in-scala-with-borachio/
|
|
|
I have a general, novice, non-Scala question about unit testing on Android. Like, how do you do it? :-) For example, let's say I am using android.graphics.PointF. And write a Java JUNIT test: public void testBah() {
PointF aPointF = new PointF(1.2f, 3.4f);
aPointF.offset(4.5f, 5.6f);
assertEquals(5.7f, aPointF.x);
assertEquals(9.0f, aPointF.y);
}
(More realistically, I'd be testing one of my own classes, but it uses PointF internally) When I run it under Eclipse, you get the Stub runtime error: java.lang.RuntimeException: Stub! at android.graphics.PointF.<init>(PointF.java:5)
Do you have to run the tests under the Android emulator, which is really really really slow? Or is there some basic workaround? Thanks!
|
|
|
Yeah, it's a problem. A big problem. Android is the most test-hostile environment I've ever had the misfortune to work with. You probably want to check out Robolectric: http://pivotal.github.com/robolectric/Whether this will work for you depends on exactly what you want to test. But if it does work for you, it'll save you lots of heartache :-)
|
|
|
Here are the basic requirements for a mocking library:
[list] [*]Decrease coupling between tests and design. Dynamically creating mocking interfaces and mock objects, freeing the programmer from supplying hard-wired class dependencies to instantiate mock objects. [*]Decrease coupling between tests and design. IDE Integration, supporting advanced refactorings to convert dynamically created mocks into actual interfaces provided by your API, enabling the developer to "raise to the surface" the API after prototyping and experimentation rather than providing a hook into everything [*}Decrease coupling between tests and design. The ability to mock everything. [/list]
What am I missing?
|
|
|
Ah, foo. I thought Artima supported the [list] post formatting markup.
|
|
|
Other thoughts:
Changed the name to Mockhiatto. It is a coffee reference, and perfect for a library targeted towards the Java Virtual Machine.
I think a name with the word "Mock" in it will do you a world of good in terms of marketing. .NET has this all over the place with RhinoMocks, TypeMock, and Moq. The name has to be so simple that somebody can say it out loud and at least part of the name should inform what it is for.
Again, I would also really emphasize my list above. I am not saying you can't fulfill that list above, but that you need to explicitly market your library as fulfilling the list. Old references to Martin Fowler posts aren't as valuable as they used to be. It is 2011. Really re-think how you market this stuff with the goal of having every Scala developer using your library to improve their quality assurance.
|
|
|
> Other thoughts: > > Changed the name to Mockhiatto. It is a coffee reference, > and perfect for a library targeted towards the Java > Virtual Machine. > > I think a name with the word "Mock" in it will do you a > world of good in terms of marketing. .NET has this all > over the place with RhinoMocks, TypeMock, and Moq. The > name has to be so simple that somebody can say it out loud > and at least part of the name should inform what it is > for. > I kind of like the name Mockhiatto. Even though it is 2011 and coffee-related names for Java things went out of style in about 1997. Maybe it has been so long that it could be cool again. Though a lot of Scala folks do know this as Borachio already.
|
|
|
Yeah - names are tough. We spent a lot of time trying to come up with names when I first released the project, and all the obvious ones were taken. In particular "scalamock" had been taken (although the project associated with it appeared to be moribund). So we ended up with Borachio :-)
I do like mockhiatto - although I fear that it might cause confusion about spelling (is it mockiato, mockhiato, mockiatto or mockhiatto? :-)
However, I've just noticed that scalamock.com is available again :-) The enhancements I'm currently working on are an opportunity to change the name - there are lots of other changes going to happen with the introduction of the compiler plugin etc. so perhaps this is a good time to change the name as well? What do you think?
|
|
|
> Really re-think > how you market this stuff with the goal of having every > Scala developer using your library to improve their > quality assurance.
Thanks for the thoughtful feedback, John. I freely admit that marketing isn't my strong point :-)
As you know, "marketing" an open source project like this is more to do with word-of-mouth than anything else. With that in mind, I'd greatly appreciate any and all help with getting the word out there and explaining the benefits of this kind of testing in different ways (I suspect that no single explanation will work for all comers).
|
|
|
A big problem. Android is the most test-hostile environment I've ever had the misfortune to work with.
|
|