36
The main problem with your idea is that you can't just write tests for any code. The code has to be testable.
I.e. you need to be able to inject mocks, separate out the bit you want to test, access state which is changed and needs confirming etc.
Unless you get lucky or write the test first, chances are writing the test means rewriting the code a bit. ...
30
The general approach of using pairs to split the effort of writing production code and writing its associated unit tests is not uncommon. I've even personally paired in this way before with decent success. However, a strict line between the person writing production code and the person writing test code may not necessarily yield results.
When I used a ...
15
The main issue I see here, at the unit level, when I write code, I want to compile it, run it, and remove the most obvious bugs immediately - even when the code is incomplete and I know the unit, feature or function is only partly implemented. And for running the code of a unit, I need some piece of program calling the implementation, usually a unit test or ...
9
To a first approximation, the stakeholders of a test suite are the code developers/maintainers. You're going to need some of their time. Insist on this.
Ask them about problems they're facing.
Ask them about bugs they've fixed recently (in the past couple of years, assuming this is a long slow project).
I get the impression that you're not expecting them ...
7
There would seem to be the possibility for any of the following situations to occur - all of which are undesirable:
Confusion
As Ewan outlined, the CUT might need changing to make it testable. The reason for the change isn't always obvious to the developer (and may cause disagreement) which is exactly why tests are written first.
Contention
Developer A ...
7
Constructors should not do work. The initialization of a new object should happen very quickly, and making database calls, or interacting with any resource outside of the current process, can take considerably longer.
Instead, your constructor should either require the data from the database as separate arguments, so that the database calls are made before ...
5
In real life, your code is going to contain real methods with meaningful names, real parameters with meaningful names, and real-life implications when they execute. It's those real-life implications that you will be testing in your unit tests, not the results of some abstract foobar if-conditions.
Each unit test should only be testing one thing, not six. ...
4
When used in conjuntion with pair programming and TDD this is called Ping Pong Pattern:
A writes a new test and sees that it fails.
B implements the code needed to pass the test.
B writes the next test and sees that it fails.
A implements the code needed to pass the test.
And so on. Refactoring is done whenever the need arises by whoever ...
3
I do not recollect any such push. I imagine it was a demonstration of interoperability in the .NET space rather than a practical use of different languages for testing. Any benefits would have been made up just to underpin the virtues of this wonderful common language runtime environment.
I guess this could make some sense for library code. If you write and ...
3
Is it bad practice to repeat logic being tested in unit tests?
No, but sort of.
No, in the sense that the tests are automated checks which verify that the test subject behaves like some simpler system. So if the problem you are trying to solve requires an elaborate dance of logic gates, then you are going to see shadows of that same logic in your tests.
...
3
I'm coming late to this party, but I think I have something to add.
Is it already described as some unknown-to-me methodology and used in software development?
You are describing Peer Testing.
Let's assume we have pairs of developers.
Ah, good ol' Pair Programing.
Each pair is responsible for a part of the code. One from the pair implements a ...
2
I'm going to assume at some point you can get the code to at least compile. If you can't even get that far you are on a fool's errand.
Lacking proper requirements, specifications, or screenshots is not a blocker for writing tests. As long as you can read source code, you can write tests.
If you are given permission to refactor the code base to isolate ...
1
Based on the description of the issue and your comments, I think the best you can do is to start with the Java API and try to build a single unit test around an isolated method.
Without access to the code, I can only give you limited guidance but I would look for something that in it that a) has no dependencies b) makes no state changes. For example. let's ...
1
I think that this idea has some upsides:
Le'ts run through them one by one.
tests are written by someone, who can see more about the implementation,
So, you mean that the first developer has spent time writing some implementation, which he is not sure works. Then, another developer comes and writes tests, basing his reasoning on code nobody knows ...
1
I've done DDT (development driven testing, aka. tests after code), pair programming and red-green-refactor TDD for several years each. To respond to your assertions point by point:
tests are written by someone, who can see more about the implementation
The person writing tests needs to know the implementation as intimately as possible, to write tests ...
1
When you instantiate the object CreditCardApplicationEvaluator, it needs to be ready to evaluate applications. We must think of the failure case where you can't pull this data from the database. So if you put the db call for those constants in the constructor, it might never return, so you will never instantiate your object or it will fail.
Also another ...
1
IMO the reason you don’t see this much anymore is because it was really just another way to put a nail in VB. The idea being promoted wasn’t that it’s good to write unit test in another language, but rather that you could write C# unit test for VB code.
This has several potential advantages. First, if your team doesn’t have a lot of c# experience, it’s a ...
1
Your second example is certainly not an anti-pattern. In fact, there are testing frameworks that support exactly that kind of tests: You write a single testcase that takes some parameters and next to that you specify a set of values for those parameters and the expected outcomes.
As your testcases are so similar, they only differ in which character for ...
1
I find the first much preferable. Here are the issues I see with the second version:
It's harder to tell what you are testing.
I think maybe it will be more difficult to know what exactly went wrong in a failed test.
It could use tests of its own which I think is a problem.
When requirements change e.g. use cases diverge, this kind of thing can be ...
1
To continue off of what @Hans said, you can't reasonably tests every situation for this ordering issue and it might be buggy on certain situations.
But there is something you can do, you could put an assert in main code to make sure it is "in order", if it is not too expensive. There are certain situations where this is acceptable, e.g. if the list is not "...
Only top voted, non community-wiki answers of a minimum length are eligible
