I've been learning about DynamicObject in .NET 4.0 and was wondering if this type would be well suited to creating mock objects.
Mocking seems like a great way to use DynamicObject, but am I missing something?
Are there any mocking frameworks that use DynamicObject (as opposed to dynamic proxies or interception) for mocking?
Are there any disadvantages to using DyanmicObject for mocking (besides requiring the .NET 4.0 CLR)?
The biggest drawback that I can think of is that you can call literally any method/property in the world on a dynamic types.
for example, think of the hell it would be to update your tests if your api changed - you tests would still all compile, however they would all die with runtime errors if they tried to exercise the renamed/removed methods.
This, combined with the fact that you lose all Intellisense when operating on dynamic objects leads me to believe that a dynamic-based mocking library would be more difficult to use that something proxy-based like Rhino.
Related
With the inclusion of Microsoft Fakes in Visual Studio 11, I thought it would be worth to look into again, since I did not find Moles mature enough last i checked. The documentation is still sparse, but I cannot find any reference to mocks, i.e. the ability to set up and verify expectations on the faked objects.
Does anyone know if this is currently included (as a feature in the library) or will be?
It is not included currently, but we are considering something in this area.
Although they are not included, you can use stubs to hack in the same behavior. In your stub you can capture whether the method was called and the parameters that were called. Of course, by the time you start doing that you're almost hand rolling your own mocks.
In the meantime I'd suggest Moq or RhinoMocks. I find the syntax simpler and I'm not a fan of the generated code that Microsoft Fakes uses anyhow. Try renaming a method on one of your fakes using a refactoring tool. It's not possible because your fake is a generated class, not an instance of the interface you are stubbing.
Why doesn’t Objective-C have namespaces? It seems like a simple feature that would make some class names more readable (AVMutableVideoCompositionLayerInstruction anyone?) and axe the silly letter prefixes on class names. Is this mainly because of backwards compatibility? Is it harder to implement namespaces than it seems?
I don't know the answer but I suspect "it's harder than it looks" is probably it. You would have to introduce support in the compiler and linker in a way that doesn't break existing software. And while this is obviously possible (C++ has already done it) presumably the tool chain team have had higher priorities on their plate. e.g. in the recent past we have had garbage collection, GCD, blocks and Objective-C 2.0 appear so we can't say they have been doing nothing.
Namespace support is the one thing that I would dearly love to see introduced to Objective-C.
I don't know if you want to know if there is some official decision.
But namespace like many other feature are choice, choice made by the language contributor.
PHP only recently introduced Namespace, and for example Java use package that act like namespace or python use modules.
I think that there is an overhead in namespace implementation, mainly because Objective-c is dinamically typed so at runtime you have to make some check to resolve the namespace, to resolve default behaviour,etc.. and I can suppose that because Objective-c is also used in embedded enviroment (AKA iPhone) speed is very important.
You've to wrap everything I've said in a big IMHO ;D
Update:
I found this very interesting discussion http://clang-developers.42468.n3.nabble.com/Adding-namespaces-to-Objective-C-td1870848.html#a1872744 on the clang developer website explaining the reason why is definitely non-trivial to implement namespace in Obj-C.
what is the difference between these two terms, thanks in advance for any good simplifications and good examples.
A framework is a group of classes, interfaces and other pre-compiled code upon which or by the use of which applications can be built.
The API is the public face of a framework. A well designed framework only exposes those classes, interfaces, etc that are needed to use the framework. Code that supports the operation of the framework but that is not necessary to users of the framework is kept internal to the framework's assemblies/dlls. This keeps the public face of the framework small and encourages a "pit of success," or the quality of a framework which makes it simple to do the right thing.
(I provide an example from the .NET world)
The SqlConnection class is used to connect to a Sql Server instance. Its public API is pretty simple:
using (SqlConnection connection = new SqlConnection(connectionString))
{
connection.Open();
// Do work here; connection closed on following line.
}
However, this class depends on around 200 methods within the System.Data framework (in this case, an assembly), 3/4 of which are internal and not part of the public API of System.Data. Because the framework's API is kept simple, it becomes easy to use SqlConnection properly. If the user was required to deal with SqlConnectionFactory, SqlDebugContext, DbConnectionPoolGroup or any of the other internal classes required by the SqlConnection class, it would become exponentially more difficult to use SqlConnection properly. Because the API only exposes a small percentage of the framework, it is easier to create and use a connection.
An API is an interface to a (set of) component(s) encapsulating a functionality. For instance, the GoogleMaps API, the DirectX or OpenGL APIs.
A framework is more a set of tools, components aimed at helping the developer to develop his/her project in a given Frame. The framework usually sets some coding standards, provides useful components, ... For instance, Symfony/Cake are PHP web application frameworks. JUnit is a framework for unit tests in Java, ...
Frameworks can often bundle/provide a unified interface to some APIs.
Some APIs can be internally built using a framework.
API - application programming interface -> the contract you must obey when using a library's API
library - a set of classes/modules that solve a specific problem -> has an API
framework - a "bigger" set of libraries with a set of rules on how to use them
Since every library has an API, no point in giving examples.
A popular Java library for time is Joda time.
A popular Java framework is the Spring framework.
You must obey a lot of rules to use Spring well. You don't have to obey as many rules to use Joda time.
An API is something code has, not something it is. A framework has an API, but it is not itself an API.
API "Application Programming Interface" is set of prewritten packages, classes and interfaces with their respective methods. You can use it without much concern about internal implementations. API is used an interface between two or more applications and like REST API.
Framework is a skeleton that contains design patterns, classes, interfaces and libraries that can be used to build applications. Framework provides inversion of control which give the responsibility of program flow to the framework itself, also we can extend the framework without changing its predefined code. For example Spring is a framework that can be used to build web applications.
API's are pre-built-in from SDK (or from which you can include on to). Frameworks are loadable bundles wherein exposed functions of such bundles can be used. You can acquire expose functions of those frameworks by using pointer to functions.
Example:
API:
-stringWithString:
function from framework:
-myExposedMethod:
Framework is use to design an application, ie MVC, MEF. Like a model that you build on, almost a base for a certain set of functionality that you might want in your application.
API is for interaction between applications, your app would use the Facebook API to interact with Facebook.
Hope this is a bit more clear.
Java API simply means ...Application Programming Interface in which all the features describes of product or software.
Java Framework means semi-completed project or code. It provides an architecture to make project . Framework have own classes and methods etc..
An API is simply a library built with a particular language that developers can use to build applications.
Frameworks are a set of libraries, just like APIs however the syntaxes may deffer of the original language. So the developer may be writing a different syntax of PHP for example when using Symphony.
The main or core difference beteen framework and API is that framework allows developer to hook into the life cycle of the objects through lifecycle callback methods mechanism whereas API doesn't do that, API is only intended to perform a functionality only.
Another way to visualize it is this: (true of any programming language)
Any(!) "piece of software that is intended to be used by another piece of software" by-definition must have some "application program interface (API)," which represents the "knobs, switches and dials" that the other piece of software is expected (and, permitted) to use. All of the internal implementation details are not visible and cannot be reached.
"Frameworks" are tools that are designed to make it easier for humans to write a particular, common, type of application – such as a web-page. The framework implements "the stuff that every such application is going to need to be able to do," and does it in one, well-tested way, "precisely so that you (the application author) don't have to." Instead of redundantly writing "the same old thing, one more time, and fretting over whether you did it correctly," you simply leverage what the framework has already done for you.
After all...
Actum Ne Agas: Do Not Do A Thing Already Done.
I have trouble understanding XPCOM. How is it different from COM? What makes it cross platform?
Is it a framework with a set of libraries that you can use to do some jobs?
Also, does Component Object Model means every functionality is implemented in component so we can use it without knowing the detail implementation?
Can you someone help me understand this please?
Thanks,
Chan.
I have trouble understanding XPCOM.
How is it different from COM?
XPCOM is Mozilla's own, cross-platform (hence the XP bit) version of COM.
What makes it cross platform?
It is implemented in a library that has been ported to many platforms by contributors to the Mozilla open-source project. You can build it or download a binary for any platform that you wish and, in the extremely remote possibility that you want to use it on a platform that is not already supported, it should be straightforward to port it yourself.
Also, does Component Object Model
means every functionality is
implemented in component so we can use
it without knowing the detail
implementation?
Yes, spot on. The idea is for a language-independent framework that enables different components to communicate and interact, without requiring any special knowledge of the language that any particular component is implemented in. So javascript code can call C++ code, for instance.
This is achieved by components publishing well-defined interfaces, using a language called IDL (or, in XPCOM's case, XPIDL). These interfaces make use of well-defined types with mappings in each of the supporting languages. Every interface inherits from a common base interface, which provides standard methods for reference-counting and type-inference (called IUnknown in COM and nsISupports in XPCOM).
Can you someone help me understand
this please?
In terms of online resources, there are dedicated areas on both the MSDN (for COM) and the MDC (for XPCOM). If you want to really understand the motivation for COM and why it is the way it is, I recommend picking up Don Box's Essential COM. And of course, if you have any specific questions that need answering, you can always come here to ask them. :)
This answer to a question about C++ unit test frameworks suggests a possibility that had not occurred to me before: using C++/CLI and NUnit to create unit tests for native C++ code.
We use NUnit for our C# tests, so the possibility of using it for C++ as well seems enticing.
I've never used managed C++, so my concern is are there any practical limitations to this approach? Are many of you doing this? If so, what was your experience like?
We do this all of the time. We have many assemblies written with C++/CLI and use C# and NUnit to test them. Actually, since our goal is to provide assemblies that work well with C#, doing this makes sure that we have accomplished that.
You can also write NUnit tests in C++/CLI and call unmanaged C++. Probably the best way is the keep your pure unmanaged C++ in a lib, and then make a test assembly that uses NUnit and links to the lib.
It works very well and gives you the benefit of having parameterised tests as well as a common test runner and framework if you're in a mixed environment.
There are two downsides, neither of which is serious for most cases:
If you're being really picky, the tests are no longer being run in a purely native environment so there's an outside possibility that something may work under test but fail at runtime. I think you'd have to be doing something fairly exotic for this to matter.
You rely on your C++ code being able to be included into a C++/CLI program. Sometimes this can have clashes with headers and it forces your code to build OK with UNICODE. In general, this is a good thing as it uncovers crufty bits of code (like inconsistent use of Ansi variants of Win32 calls). Bear in mind that it's only the headers being included so what it may well show is that you are exposing headers at too high a level - some of your includes should probably be within your cpp implementation files.
My experience is that it is not possible to use NUnit to test C++ native code through C++/CLI because you will have trouble loading and using native code.
I have tried using nunit to load a basic c++/cli test dll linked against "just thread" which is an implementation of the c++ standard thread library.
Test dlls won't even load with the latest version of NUnit (2.6.2).
So definitely not the way to go!
I never used one, but isn't there a port? Perhaps http://cunit.sourceforge.net/documentation.html would work for you.
The biggest concern is the learning curve of the C++/CLI language (formerly Managed C++) itself, if the tests need to be understood or maintained by non-C++ developers.
It takes a minimum of 1-2 years of C++ OOP experience in order to be able to make contributions into a C++CLI/NUnit test project and to solve the various issues that arise between the managed-native code interfaces. (By contribution, I mean being able to work standalone and able to make mock objects, implement and consume native interfaces in C++/CLI, etc. to meet all testing needs.)
Some people may just never grasp C++/CLI good enough to be able to contribute.
For certain types of native software libraries with very demanding test needs, C++/CLI/NUnit is the only combination that will meet all of the unit testing needs while keeping the test code agile and able to respond to changes. I recommend the book xUnit Test Patterns: Refactoring Test Code to go along this direction.