Rhino Mocks - Difference between GenerateStub<T> & GenerateMock<T> [closed] - unit-testing

Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
Can any of the Rhino experts explain me by giving a suitable example of the difference between the above methods on the MockRepository class (Rhino Mocks framework).
Where should one use Stub over Mock method or otherwise?

you should use a mock when you are going to verify that something happened on the object, like a method was called. You should use a stub when you just want the object to be involved in the test to return a value but it is not the thing you are testing. A stub which does not have a expectation fulfilled can never fail a test.
I think the general rule should be that you should only ever have a single mock object in a test, but may have several stubs which provide information to the mock object. I believe that more than 1 mock in a test is a code smell.
Although not a Rhino example Martin Fowler has a description of the difference
Also this question might be useful as might this one

Related

Can you write a unit test for a unit test? [closed]

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 2 years ago.
Improve this question
Kind of a meta question, but I was wondering if there would ever be cases where writing a unit test for a unit test would make sense.
You don't have to write a test for that, generally its considered Mutation Testing.
Mutation Testing is a type of software testing in which certain statements of the source code are changed/mutated to check if the test cases are able to find errors in source code. The goal of Mutation Testing is ensuring the quality of test cases in terms of robustness that it should fail the mutated source code.
From Guru99
There's a few well known examples,
PIT for Java
MytPy for Python
Stryker looks like its the one for Javascript.
You could write you own tests that mutate your code itself, but its sensible to use OSS projects and help contribute to them if theres any unique needs given the complexity of the area. You don't want to have to own your own mutating framework either and all the maintance with that.

(How) Do you test your dependencies in your unit-tests? [closed]

Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 2 years ago.
Improve this question
Should you include testing external dependencies in your unit-tests, eg. not mocking the objects in the dependency but actually creating an instance in your unit-test as to ensure some third party didn't do something stupid like creating a BC-break in a patch release. If so, how do you do this? I can assume that automatically instantiating external code could lead to serious security vulnerabilities.
So after some great comments from #Nkosi I have come to the conclusion that this should not be a part of your unit-test suite. However to correctly test against deficiencies in external dependencies, integration tests should be set-up.
While looking into integration testing I came across a great answer about the balance between unit-tests and integration tests on StackExchange: https://softwareengineering.stackexchange.com/questions/208458/when-should-i-write-integration-tests#answer-208465

Unit Testing Azure Function with Change Feed Trigger [closed]

Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 4 years ago.
Improve this question
I'm trying to write a unit test for an Azure Function with Change Feed Trigger.
Is it possible to trigger the function using document db emulator?
or
Should I call onto the function directly?
e.g., FunctionClass.Run(documents, null);
Also, is there any example on creating unit test for azure function?
I wasn't able to find any examples for similar cases.
Thanks
Unit testing means testing code in isolation, without dependencies on things like DB emulators.
So yes, just use your unit testing framework of choice and call Run directly, mocking any internal dependencies if needed.
You can find a couple examples in this repository.

Mocking in Unit Tests for behavior. Why is verifying a method call beneficial? [closed]

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I see lots of developers writing unit tests like this:
[TestMethod]
public void AddTrainer_InvokesProviderAddTrainer()
{
//ARRANGE
var trainerBusiness = new TrainersBusiness(_trainerProviderMock.Object);
//ACT
trainerBusiness.AddTrainer(new UserProfile());
//ASSERT
_trainerProviderMock.Verify(v => v.AddTrainer(It.IsAny<UserProfile>()), Times.Once);
}
I understand what is happening, I just don't quite what problem this intends to solve. Here the test is proving that the AddTrainer method in the business object is calling the AddTrainer method in the provider.
As long as the trainer is correctly added, what is the importance to me how the business method goes about doing it? To me this means if we decide we want to change the way the business method goes about adding a trainer in future, even though the trainer is still added, this unit test fails and we have to rewrite it.
It seems to me that this type of test is just confirming no one has changed your method, a bit like a checksum, rather than confirming anything useful with the behavior.
What am I missing?
You see this frequently in Unit Tests of void return methods because people don't know what to assert. Sometimes it's a good idea and sometimes it is just to get high code coverage numbers. I think the example you have falls under code coverage. The key for me is the "It.IsAny" usage combined with the name of the test method. The author could just have named it AddTrainer_GetCodeCoverage. If you had 2 tests named AddTrainer_ValidTrainer_InvokesProviderAddTrainer and AddTrainer_InvalidTrainer_ThrowsSpecificExeception each making different checks on the Mock and confirming the values passed to the mock, you'd have something of value.
This is to make sure that no one messes with the TrainersBusiness.AddTrainer method by adding some condition which would prevent UserProfile from adding into the TrainerProvider

Differences between EasyMock and Mockito [closed]

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I'm learning testing with EasyMock and Mockito. What are differences between them?
What are advantages and disadvantages of any of them? Which one is better to use?
Although this question is majorly opinion based but you get the differences from here:
Differences:
no record/replay modes - no need for them. There only 2 things you can do with Mockito mocks - verify or stub. Stubbing goes before execution and verification afterwards.
all mocks are 'nice' (even somehow nicer, because collection-returning methods return empty collections instead of nulls). Even though mocks are nice, you can verify them as strictly
as you want and detect any unwanted interaction.
explicit language for better readability: verify() and when() VS the mixture of expect(mock.foo()) and mock.foo() (plain method call without 'expect'). I'm sure some of you will find this argument subjective :)
simplified stubbing model - stubbed methods replay all the time with stubbed value no matter how many times they are called. Works exactly like EasyMock's andStubReturn(), andStubThrow(). Also, you can stub with different return values for different arguments (like
in EasyMock).
Verification of stubbed methods is optional because usually it's more important to test if the stubbed value is used correctly rather than where's it come from.
verification is explicit - verification errors point at line of code showing what interaction failed. verification in order is flexible and doesn't require to verify every single interaction.
custom argument matchers use hamcrest matchers, so you can use your existing hamcrest matchers. (EasyMock can also integrate with hamcrest though it is not a part of EasyMock but hamcrest. See the
documentation of hamcrest).