What's the best mocking framework syntax-wise and capability-wise ?
My problem: Most mocking frameworks use lambda expressions now, which are really ugly to write in VB.NET, so is there any framework that has nice syntax without lambdas or has fluent syntax that doesn't need lambdas?
I think capability wise Typemock is the best framework for .Net, instead of working within the runtime it hooks into the CLR and can intercept about any call. This enables you to mock and test anything you want. Some people think it's too powerful. It allows you to test anything while usually the fact that you can't test something is a good warning that there's something wrong with your design. Also it's not free.
I mainly use Rhino Mocks. It has a really readable syntax, especially the new AAA syntax. Moq is quite new and should be good too, syntax wise. Although I haven't tested it yet.
rhino mocks.
But you could have trouble with the new lambda-expression syntax (especially when setting expectations on subs) so either use the new syntax or be prepared to work around it.
Typemock's VB APIs are very simple to use, and it has all kinds of functionality like faking Shared functions.
FYI, Isolator has VB.NET specific API so you should be able to use it easily:
http://www.typemock.com/vbpage.php
However, it is a commercial product.
Related
I would like to be able to do some unit testing during development in order to catch potential errors when extending/changing the way a given web service (endpoint) works.
I have been looking at EasyMock, and this seems like a viable way to go - but!... I'm using maven (2.0.9) and would like to test e.g. with mvn test, but this requires that my backend is running or that I use EasyMock - which then requires that I can connect to a database (thus this needs some mocking as well). The web services I currently have all retrieve data from a backend base...
As I have 15 or so web services used by different parts of the organization in different versions I would very much like to be able to test that changes doesn't break older versions.
I cannot believe that I'm the first person to have this problem, so any hints, tips, or likewise would be much appreciated.
After comment-based talk :P, it seems that there's no problem actually. The key thing was to understand that some component's dependencies (like database) are just its real implementation dependencies and are not part of its interface. And mocking is about providing alternative implementation, to just satisfy a need for interaction.
In general, as you mentioned, all stuff you depend on in backend need to be mocked (or doubled in general) when unit testing, no matter what this stuff really is. If you depend on some external endpoint, you have to mock it. If you depend on RDBMS, you can mock it too, but probably better test double here would be fake instead of mock, so you can use some in-memory database (like HSQL or H2), assuming you're not using vendor-specific, native SQL in your code. In fact, you're still providing some own, usually simplified implementation of some interfaces, but nowadays you use mocking framework for this. Some time ago, developers write own, hand-crafted mock classes. Even today, it's sometimes really good idea to made own mock without help of mocking framework. Personally I encounter such special situation where this approach fits pretty well.
By the way, two more things. If you consider doing some integration testing as well, Spring WS since 2.0 version provides module spring-ws-test that supports this pretty well by providing really fluent API. For more info look at Spring WS docs, if you're interested. Second thing, if you're just starting with mocking in general, also consider using Mockito. In my opinion, it's really good as well. To be honest, EasyMock is my personal default choice for mocking lib, but I found Mockito similarly easy and powerful. As far as I know, it's prefered by many developers as well and nowadays it's probably more sexy :P.
Is there a comparable and reliable alternative for Rhino Mock library.
I am using Rhino now for MVC ASP.NET project, but am considering (just as plan B) to see if there are any other equivalent alternatives.
RhinoMocks is a very good and powerful Dynamic Mock library. Even though I have been using it for years, I recently switched to Moq.
To my knowledge, RhinoMocks can do everything Moq can do, and perhaps more. The reason I switched is because RhinoMocks has so many different ways you can do the same thing.
To avoid confusion (particularly for colleagues new to mocking in general), I decided to switch to Moq because it has a cleaner API.
Moq is a very good alternative
I advice moq.
There is also NMock which is very old and I believe uses a lot of magic strings. TypeMock Isolator can do way more (including mock DateTime.Now) but costs money and tends to be used more in hard-core legacy application mocking so it can encourage poor discipline.
I really like the moq mocking framework. I've used it on several projects. Unfortunately, one of my customers is demanding we use VB.Net. Not my preference, but hey, .Net is .Net, right?
I've heard that moq has some trouble with VB. Is this true? Is so, what sorts of trouble? I would expect it to work fine given the language agnostic nature of .Net.
Should I look into using some other mocking framework for use with VB?
The main problem of VB.net with regards to mocking frameworks is that, contrary to C#, VB does not have anonymous methods, only Lambda expressions (no way to declare an anonymous Action delegate).
This severely limits the possibilities.
There is also a known issue with properties with parameters.
Also, the syntax of the language for lambdas does not lead to something as clean as C#, readability-wise (no flames please, I'm a VB user and I miss some C# features every day), and that's partly the attraction for Moq.
The only testing framework I know of that did something with regards to VB is TypeMock. They tried to design something that blends with the VB syntax.
AFAIK Typemock Isolator is the only tool that can fully mock VB.NET. They made an API especially for that.
I'm considering building a framework for VB.NET, and using the My namespace to plug it into VB seems like a reasonable idea. What is "My" used for?
The purpose of My, as I understand it, is to be an easy shortcut to certain API tasks that are common but hard-to-find or hard-to-use. You probably shouldn't completely subsume your framework under My. (For one thing, C# people using your framework may get grouchy.)
Instead, you should design it as a normal framework. When you're finished, make a list of some common tasks that people might want to use your framework for. See whether any of those could be useful to have under My, especially where there are classes or methods that can be used in a number of ways, but they have one or two really common usages that can be abbreviated with My.
This article shows how to extend My, and it has a section at the end that describes a few design guidelines to follow: Simplify Common Tasks by Customizing the My Namespace
As to your main question, when coding in VB .NET, I use My as often as I can. It reduces a number of operations to one line of code.
I really like the "My" Namespace in VB.NET and I always use it in my WindowsForms applications, because it is very intuitive.
I use primarily these categories:
My.Computer: primarily for file system and network purposes
My.Application: Version number, current directory
My.Resources: Access to resources used by the application residing in resource files in a strongly typed manner.
My.Settings: very handy
I think, if your extensions for My of your framework fit well, then many VB.NET programmers would appreciate them.
I've used My in my VB.NET projects, and I don't feel guilty about it. I am primarily a C# guy, but until I transitioned my company to C#, we were a VB shop. In my mind, the My namespace is a nice piece of syntactic sugar. Just as I'm not embarrassed to use C#'s coalesce operator and other sugar, I'm not embarrassed to use VB's sugar, either. (To an extent; I won't use the classic VB functions that .NET still exposes.)
That said, never put anything in that namespace. It's Microsoft's namespace, and just as you wouldn't put anything under System nor Microsoft, don't put anything under My. It will cause confusion later on -- if not for you, then for others who maintain your code. Create your own namespace for your own code.
We do use it in some code, but hesitantly so. It's true that My often helps make code more readable. For example, the Environment.SpecialFolder enumeration curiously lacks a Temp member, whereas My.Computer.FileSystem.SpecialDirectories has one (Path.GetTempPath() will do as well, but is hardly intuitive compared to other special folders).
But My is only beneficial in such cases because the existing APIs are badly-designed, not because My is inherently better. Like JAGregory, I strongly suggest one avoids extending My — or any other kind of global namespace, variable, etc. — whenever possible. The idea just doesn't fit a clean OOP architecture.
I never use the My namespace (I'm a C# developer), but my VB co-worker doesn't as well. I found the My members not necessary, because in many cases, they're counter-intuitive for me, e.g. in my opinion opening a file has something to do with IO (hence System.IO.File) and not with my computer (My.Computer.FileSystem). They always seem so scattered and bunched together.
It's just some re-roll of functionality that is already available otherwise, from all languages. And I don't like depending on Microsoft.VisualBasic.dll when I'm developing for .NET - I always prefer System.*.
And then, it's always kind of limited. I see VB developers struggle with their app when they can't find something in the My namespace, because they can't imagine that you can use something in the System namespace. That of course is not a problem of the My namespace itself.
I mainly use C# and Boo, but when I do use VB.NET I use My namespace quite often. I dont see any reason to not simplify coding. It still retains its readability.
I've only used it from a user perspective, I've never plugged anything into it. I consider the My namespace to be some highly reliable, platform-provided, global helper mechanisms. Officially sanctioned shortcuts, really. I might be surprised to see external user or third-party code in there.
As such, I'd encourage a vb framework to define its own appropriately-named namespace instead of latching on to the existing My namespace. Such a framework shouldn't have that "global" feel to it.
Never used it so far, although I've never actually looked into it either.
I wouldn't advise putting anything into the My namespace yourself, it's much more clear just to lay it out like you would if it were a non-VB framework.
Love the My! Anything that helps me get the job done faster, and provides code for solutions that I don't have to write, the better!
I use My.Settings and My.Computer often while programming in VB.NET. I particularly enjoy My.Settings as an alternative to using ConfigurationManager.AppSettings when it is appropriate.
I agree with John Rudy about the use of My. It is syntactic sugar that makes life a little more readable.
I don't use it a lot.
I'm considering building a framework for VB.NET, and using the My namespace to plug it into VB seems like a reasonable idea. Is it?
If it fits, by all means, use it. Since you didn't offer any further information about your framework it's hard to say. I wouldn't put general-purpose stuff into the My namespace (such as the My.Computer stuff) because there isn't really any advantage to putting it there. However, application-centered helpers fit in well.
I am interested in writing static code analyzer for vb.net to see if it conforms to my company standard coding guidelines. Please advise from where i have to start.
Rather than write your own static code analyzer, I recommend you use FxCop: and instead, write custom FxCop rules for your needs. It'll save you a lot of time.
http://www.binarycoder.net/fxcop/
I would suggest you use Mono's Gendarme. It's a very nice tool, with plenty of built in rules. It also generates nice HTML reports.
if you need mroe architectural insight use NDepend. This tool does not stop to amaze me. It can do soo much more than FxCop. It's commercial though, but has a free trial version
FXCop is a good start for coding problems/mistakes, StyleCop is good for coding style (obviously), but if neither of those two work then you then you can either write a parser yourself or use the VBCodeProvider class in the .Net Framework
Start with FxCop. If you can't do what you're trying there, try something like NStatic or NDepend.
The best options are to use FxCop or StyleCop and write custom rules if necessary.
Use FxCop, this isn't a project you want to undertake personally. The parsing/lexical rules involved and the possible catches would be insane. The only way I could imagine doing it while retaining a modicum of sanity would be to use Lisp thanks to the extreme amount of expressiveness, but again, best to use FxCop.
If you must write a custom in-house tool for some (dogmatic?) reason, I'd recommend writing a Lisp program that does only basic rules-checking. Don't try to make it comprehensive, we're talking the kind of frontier that AI researchers are dealing with in terms of the parsing capabilities of a piece of software.
Just use Lisp to find the possible obvious offenders, or just at catching whatever it ends up being good at catching in terms of non-compliant code, then subject it to a brief human eye scan. I highly recommend abusing macros if you do use Lisp to write the parser.
I agree with one of the posters that it would be a quite difficult taks, but rather than with Lisp I'd start with F#, just like Microsoft did for their 3rd party windows drivers analysis tool:
http://arstechnica.com/journals/microsoft.ars/2005/11/10/1796
F# shares Lisp's expressiveness (ok, almost) and works on CLR just like VB.NET, which would make the whole thing easier.