I've been using RhinoMocks lately but I keep running into an issue. If I break into the debugger and step over code while a mock is in Record mode, I end up getting an exception along the lines of:
System.InvalidOperationException: Previous method 'SuchAndSuch.ToString();'
requires a return value or an exception to throw.
But if I execute the same code without breaking into the debugger it will execute successfully and create the mock.
I'm pretty sure that the reason for this is that the debugger calls ToString() on objects to display them in the Locals and other Watch windows. But since the mock is in record mode RhinoMocks considers a call to ToString() to be a setup of expectations which then isn't completely correctly. Obviously this only happens with partial mocks on concrete classes. Mocks against interfaces do not exhibit this behavior.
Have other people run into this issue? Is there any simple remedy? Do other frameworks such as moq or TypeMock have this issue?
Thanks,
~ Justin
I can remember having a similar issue with NMock many years ago. Basically, this problem occurs exactly because the debugger invokes and displays properties using the ToString method (unless you use DebuggerDisplayAttribute or similar).
This can be particularly problematic if you use strict mocks because they only allow you to invoke a member the specified number of times, and the debugger interferes with this. Using loose mocks addresses this (and many other) problems.
You may also want to move away from the record/playback mechanism of Rhino Mocks and begin using the newer and much better lambda syntax.
Moq uses lamda syntax (almost) exclusively, and I've never had such issues with it - but then again, I don't debug much these days, as unit tests have become a substitute to debugging.
Yet another remedy is simply to hide the Autos and Locals debugger windows.
As Mark suggested, this problem should go away if you stop using the record-replay-verify approach and start using stubs with the recommended AAA approach (arrange, act, assert) instead.
I've tried to explain the difference and how to do both with Rhino Mocks in this blog post.
Related
Ethereum/smart contracts enthusiasts,
I want to execute some code which does not modify the state variables on my own Geth ETH-Node without deploying a contract. Is that somehow possible?
My current thoughts:
I have debugged the geth a little bit. I found by executing a view function the StaticCall is executed from the evm class. It seems at this point I can also inject some bytecode of my own view functions, without deploying it. From my understanding, a view function does not edit some state variables it only reads and returns them. This would mean I can technically do that, without destroying the chain. But this way of changing the code seems to be a little bit oversized, is there a simpler way?
Thanks.
It is not possible. You need EVM to execute the code. The EVM is an entirely isolated and sandboxed runtime environment. There are some key elements that are required by the execution environment to execute the code.
Deploying a contract is creating an instance of a contract. Then you interact with the contract instance
I've been asking myself whether there is an easy way of debugging the JavaScript code of the transactions. JS already has mature debuggers, it is only a question of how to easily bind it to the code running in the container. Does anyone have a clue? -- Thx.
One of the easiest ways to debug your transaction code is to deploy your business network into an embedded fabric which basically means that your code is run as any other NodeJS app is and you can use the node debugger to step through your code or even simple console.log statements if that suffices.
To get an insight into how to achieve this, have a look at the code here: UPDATED LINK
https://github.com/hyperledger/composer-sample-networks/blob/master/packages/carauction-network/test/CarAuction.js#L31-L49
This is the beforeEach method of a unit test for the sample network and as you'll see, it deploys the network to the 'embedded' fabric.
The code then goes on to perform tests that include calling the submitTransaction API on the embedded businessNetworkConnection which then causes the Transaction script code to be eval'ed by the embedded fabric.
So it's all happening within a single Node app and is much easier to debug.
HTH
The team I am working with has bought a CloudPort license (from CrossCheck Networks) and we are currently facing the problem of not being able to implement any sort of logic in the service Mocks (to control response selection). It would be something as simple as:
if (requestCounter++ == 1)
then
response = $fn:Global(MyFirstXmlString)$ // <-- this is CloudP syntax for vrbls
else
response = $fn:Global(MySecondXmlString)$.
We did not find any sample for using the Dll Plugin and neither of the two JScript and VBScript Tasks are working (i.e., our client machine gets back not the desired MySecondXmlString response but instead a Fault with
<faultstring>
ActiveX control '0e59f1d5-1fbe-11d0-8ff2-00a0d10038bc' cannot be instantiated
because the current thread is not in a single-threaded apartment.
</faultstring>.
Believe it or not, the fault above is being obtained even if the J- or VB-Script task is left empty! It's hard for us to believe that all the logic functionality advertised in the CloudPort UI is fake and that nothing is able to help one implement the kind of logic described above.
Any help would be appreciated!
Thanks,
Pompi
PS: A bit more details here on why the kind of logic described above is needed: We use SoapSonar in our testing framework to fire requests to a BizTalk orchestration application. The CP mocks are needed to simulate the environment of that BT orchestration. We cannot control individual mocked responses via SSonar requests: the (for cloudport: incoming) client requests are made by Production code and cannot be altered or controled by our SSonar client). The only Tasks functionality that worked for us is a DB-table working as an offline channel b/w SSonar and CP (SSonar writes in it and CP reads from it). CloudPort's reading of, say, responseXml's, from DB works fine but we cannot find a way to implement further behavior controlling logic on the CP side. Therefore, this stackoverflow posting. And thx for having the patience to read this whole shananigan :).
Don't think you can control this from the script.
The threading model should be controlled by the host, which I suppose uses windows's "vbscript.dll" for the actual execution.
So if you cannot find any settings under the tool's options or in the help :), you should look in the registry keys for the threading options of that ActiveX or "vbscript.dll"
That is the "ThreadingModel" value and try to change the values (you will also have to search the net for those, don't know them by heart).
There are chances that some other application (antivirus?) has changes the path to the dll that the COM interface should actually point to (see http://social.technet.microsoft.com/Forums/en-US/ieitpropriorver/thread/ac10bd5f-6d91-4aac-857c-0ed5758088ec)
Hope it helps.
In my code that runs on eventmachine, how do I know if EventMachine::stop has been called?
I need this so that in my deferrable I do not log error messages that result solely from closing a connection and thus are not interesting from the operations stand point.
Is the only way to monkey patch the code?
If you have a peek at the source code for the pure-Ruby implementation of the EventMachine class in lib/em/pure_ruby.rb there's an instance variable defined called #stop_scheduled. It seems to be used internally to do exactly what you want to do - not perform some operations if we're currently shutting down.
Unfortunately this variable isn't exposed as part of the EventMachine API so you can't use it.
You might be stuck having to re-implement this kind of functionality yourself. Add a instance variable to the appropriate class(es)and have some guards around code that you don't want executed if a shutdown is in progress.
I am trying to override the singe instance limit of an application for which I don't have the source. I know that the app is using the good ol' trick of using CreateMutex to determine whether there is another instance running. (If the mutex is created successfully it proceeds, if getlasterror says that the mutex has been created it quits immediately). I found that through sniffing the Win32 api calls.
I thought using Detours would do the trick, but it doesn't quite work out. I am intercepting CreateMutexW, but for some reason, it doesn't catch the first four calls to it. (Again I know what these calls are by sniffing win32 calls and looking at the name of the mutexes). I do get the fifth one intercepted, but the one I actually want to intercept is the first one.
I am using detours through the sample application withdll. I wonder if the problem is that detours is kicking in too late or because of some kind of protection these calls may have. Is detours the best approach? Perhaps using something else may be a better idea?
There might be several reasons for the situation you describe. Here are the most probable of them:
The CreateMutexW call you need to catch occurs within the DllMain
method of one of the DLLs that are imported by the process, and you
are using the DetoursCreateProcessWithDll() function to inject your
code. Detours injects your DLL by placing it at the end of the
process executable import list, and hence all the DLLs that are
imported by the process would be loaded and initialized within the
process prior to yours. In order to overcome this, try using
CreateProcess(CREATE_SUSPENDED) and CreateRemoteThread()-based
injection, although this method raises its own challenges.
The API that is used in the first call is different. Have you tried
overriding CreateMutexExW? Are you sure ANSI methods call Unicode
ones?
Hope this helps.