58
This answer consists of two separate views on the same issue, as this isn't a "right vs wrong" scenario, but rather a broad spectrum where you can approach it the way it's most appropriate for your scenario.
Also note that I'm not focusing on the distinction between a fake, mock and stub. That's a test implementation detail unrelated to the purpose ...
19
How do I really write tests without mocking/stubbing?
You design your code such that it can be tested without mocking and stubbing.
That's one of the important, if perhaps subtle, ideas behind TDD: that testing is a first class concern. In other words, our designs not only have functional requirements (does our code tell the machine to do the right thing), ...
16
I'm self-proclaimed classicist myself, so let me clear things up a little.
First, the unit vs. integration tests. For me, 'unit' test is one that is independent of other tests and doesn't require any external service. It is not relevant how much code this 'unit' test covers. 'integration' test is one that is either not isolated from other tests (maybe there ...
10
Let's get rid of labels such as mocks and stubs for a moment, and focus purely on the TDD process. You're starting to write the first test for UserService (I'm going to use your own example):
If UserRepository returns null, then UserService should return false
You've just discovered a new interface called UserRepository that UserService depends on. Now you ...
10
Customers generally at least begrudgingly understand if you can't reproduce a bug, especially if you have worked with them and made very visible attempts. What it usually takes to close such bugs is some sort of mitigation.
If it happens again, have you put something in place that will prevent data loss, give you more info to be able to track it down, etc. ...
7
1) You Ain't Perfect
Even if you had a great upfront design handed to you by some sacred initiate of the divine architectural order. You are probably going to make a mistake.
Now you could write out all of the code upfront, exactly to specification, and then press the compile and run button.
But it probably won't compile.
You have probably made 3-4 mistakes ...
6
Call outside resources through a public API customized to your apps needs. Doing so makes your dependence on outside resources explicit. This provides flexibility when those outside resources need to change.
That said, private methods rarely need a unit test written against them. Obtain code coverage by calling the private method through the public method ...
5
Is this a code smell/bad practice?
Yes. The urge to test is good, but you're trying to test the wrong thing.
require me to mock certain helper methods because they call outside resources. As a result, I'm forced to convert all my helper methods from private into public.
You don't mock the helper methods, you mock the outside resources1.
From the ...
5
You create tests to prove that something works correctly, and you re-execute those tests to prove that it still works correctly.
For determining if it makes sense to run a particular set of tests in multiple environments, you need to check what the differences are between those environments and if those differences might have an effect on the outcome of the ...
4
Sometimes just implementing a feature can be tricky enough, and if you can't even get it working the "dumb" way, then trying to make it look good is pointless. This is often quoted as "make it work, make it right, make it fast".
The "green" step lets you know when you're done writing the minimum code required to make a feature work, and ensures you don't ...
4
No, your example does not show the self-shunt pattern.
The self-shunt pattern can only be implemented with testing frameworks where the testcases are either a class or a method within an explicitly defined class. The bottom-line is that you must write that class. It cannot come from the testing framework.
A second requirement for the self-shunt pattern is ...
4
I don't have access to the image but from your explanation I understand that "sandbox" is a fork of "master" where features are merged to be tested.
There are multiple ways to solve this depending on your system and process
Scrap "sandbox", customer test on "develop". You still branch from develop for fixes in case of customer feedback. Stop merge into "...
4
For a given requirement, a simple solution design that make us think about creating good abstractions and then Implement with testing looks very intuitive.
You're right that a good abstraction is very important. So important that before you settle on an abstraction it's worth writing code that uses that abstraction and seeing what it will look like.
Oh ...
3
It's the second one.
Tests can demonstrate the capabilities of the system X as of now. But virtually always, requirements change and we will have to create a new System X' with subtle or big changes. Often, making these extensions breaks existing functionality, and then it is much more valuable to get the feedback "the email header input parser broke&...
3
or is it just Unit Testing?
There is nothing "just" about Unit Testing.
The distinction between Integration Testing and Unit Testing seems to be different in every shop. However, the most useful distinction I've ever found doesn't come from Uncle Bob. It comes from Michael Feathers:
A test is not a unit test if:
It talks to the database
It ...
3
You need to do the risk-benefit analysis of each approach.
Why does this code "need" some unit testing? What actual benefit is this going to give?
How much risk is it to refactor it to be unit testable in a "standard" fashion?
How much risk is it to use PowerMock?
We can't answer any of those for you, because we don't know your code.
...
3
As your image shows, the Sandbox branch can contain commits from (multiple) unfinished features. This means that in practice, what gets tested is never the same as what gets merged into develop nor the result of merging a feature into develop.
Your features may have been independent enough that this didn't bite you, but someday it will. And the fact that ...
answered Jun 10 at 13:53
Bart van Ingen Schenau
58.8k10 gold badges92 silver badges149 bronze badges
3
This is possibly going to be controversial, but it needs to be said:
How much testing of that kind of code do you really need?
Think about it like this: most of us would agree that in a well-architected system with good separation of concerns that the business logic is factored out from incidental concerns like I/O.
I would contend that in such a system (you ...
2
Equality is all about semantics: what does it mean that two C objects are equal? That all values of all its attributes are the same? Or can we ignore some mutable attributes in the comparison? What about references to other objects: must they be identical or is it sufficient that the value of the objects referred to is the same? Or do we just look at the ...
2
Usually in such complex situations you aren't looking for the object to have strictly not changed, just that it has behaviourly returned to the state prior to the call.
Configuration is like a mini-language, controlling the function/object being used. Comparing the configuration prior/after a call is a good way to detect many state changes.
Another useful ...
2
Is TDD a brain wash?
Maybe. I think you can make a case that discource during the Look, Ma, No Hands era was dominated by vagueness and faith.
But Red/Green/Refactor itself has held up pretty well.
Why would a good Software engineer, make the test work quickly, committing whatever sins necessary in process?
Because the GREEN task is about test ...
2
Make the test work quickly, committing whatever sins necessary in process
The word "necessary" is key here. You obviously shouldn't make any of the existing tests fail unless that is necessary to make this test succeed. It is common for a change to make it necessary to also modify other tests to make them all pass. This is completely normal. You also ...
2
Others have pointed out that your sandbox branch is flawed, your diagram even shows code being merged into and passing its test when the code is in a failed state from the previous feature.
However, I think you have bigger problems
[feature is merged into sandbox] Then the customer goes into the sandbox, tests the feature and says
either "fail" or "...
2
This question is about parts and whole:
A system is made of many parts. Each part can be thoroughly tested with unit tests.
The system as a whole can be tested with end-to-end tests, regardless of its inner structure.
Suppose you have a magic tool that finds all the possible scenarios to test. You then test every scenario and all pass: you’re in an ideal ...
2
Respond politely and honestly.
Document your attempts to reproduce the bug. Add logging capabilities if possible. Clean up the code around the bug to the best of your ability.
If this bug ever comes up again, you want to build up a backlog of evidence on how to fix it.
Sometimes you'll fix the bug while working on other things and never notice. Sometimes a ...
2
End-to-end tests and unit tests complete each other. They test code from different perspectives. End-to-end tests are focusing on a given feature, as it is implemented. Unit tests, on the other hand, test the actual algorithms in isolation. If you don't have unit tests:
You cannot say with confidence that your algorithms are actually tested.
Imagine an ...
1
As of right now, end-to-end, or system tests are always orders of magnitudes slower, harder to implement and harder to run than unit tests.
The main advantage of unit tests is that they provide you confidence in your code in matter of seconds once you make a change in the code. They are also easier to run as they shouldn't require any changes to your system ...
1
For me unit tests are as much about code design as they are about code quality. You suggest this in your first point and I don't think it's a trivial benefit.
Well designed code tends to be easier to unit test, so the activity of writing tests encourages the developer to write better code. It encourages a more conscious thought process about how the code ...
1
OK here is my understanding of your problem.
public class 3rdPartyController
{
public 3rdPartyView View {get;set;}
}
You can't change either 3rd party class, but you need to add some functionality to subclasses of them, enforcing that the subclassed Controller use the subclassed view
The view is easy:
public class MyView : 3rdPartyView
{
public ...
1
I'm forced to convert all my helper methods from private into public.
Is this a code smell/bad practice?
Yes; it is actually suggesting two different concerns.
One of the motivations for adopting TDD is the idea that creating a design that is easy to test will also give your design a lot of properties that are desirable for long term maintenance and code ...
Only top voted, non community-wiki answers of a minimum length are eligible
