Tag Info

Hot answers tagged

352

Our strategy is: Check in a failing test, but annotate it with @Ignore("fails because of Bug #1234"). That way, the test is there, but the build does not break. Of course you note the ignored test in the bug db, so the @Ignore is removed once the test is fixed. This also serves as an easy check for the bug fix. The point of breaking the build on failing ...


200

Your project is big enough already. In my experience, one class and one function have been sufficient to consider the need for unit testing. class Simple { boolean reallySimple() { return true; // how do we make sure it doesn't change to false? } } class SimpleTest { void assertReallySimple() { ...


135

You generally don't unit test private methods directly. Since they are private, consider them an implementation detail. Nobody is ever going to call one of them and expect it to work a particular way. You should instead test your public interface. If the methods that call your private methods are working as you expect, you then assume by extension that ...


114

In my opinion: yes they are, and yes you should. They give you confidence in the changes you make (everything else is still working). This confidence is what you need to mold the code, otherwise you might be afraid to change things. They make your code better; most simple mistakes are caught early with the unit tests. Catching bugs early and fixing them is ...


112

Modifying code to make it more testable has benefits beyond testability. In general, code that is more testable Is easier to maintain, Is easier to reason about, Is more loosely coupled, and Has a better overall design, architecturally.


111

You definitely should put your tests into the repository. Tests are in my opinion part of the code and can help others immensely to understand it (if well written). Besides, they can help others when changing or contributing to your codebase. Good tests can give you the confidence that your changes do not inadvertently break anything. The test code should ...


103

I've never bought into the "you must unit test everything" idea, though there are certainly folks out there who have (see gnat's answer!). As far as I'm concerned, the main benefits of unit testing are: Helping ensure changes don't break things. Helping you design sensible interfaces to your classes (since it forces you to be a client to your own code). ...


97

With 65 billion tests, it sounds like you're being asked to test all possible inputs. This is not useful--you'd essentially be testing that your processor functions correctly, not that your code is correct. You should be testing equivalence classes instead. This will drastically reduce your range of test inputs. Also consider whether you can subdivide your ...


92

Why would you want to allow a build to succeed with known defects? Because sometimes, you have time constraints. Or the bug is so minor that it isn't really worth delaying the shipment of the product for a few days needed to unit test and fix it. Also, what's the point in breaking the build intentionally every time you find a bug? If you found it, fix ...


90

Here's my personal unscientific impression: all three reasons sound like widespread but false cognitive illusions. Sure, the existing code might be wrong. It might also be right. Since the application as a whole seems to have value to you (otherwise you'd simply discard it), in the absence of more specific information you should assume that it is ...


84

No. The concept behind unit tests is based on a premise that has been known to be false since before unit testing was ever invented: the idea that tests can prove that your code is correct. Having lots of tests that all pass proves one thing and one thing only: that you have lots of tests which all pass. It does not prove that what the tests are testing ...


82

I don't think it's necessarily a bad thing, but I do think we should strive towards only having single asserts in our tests. This means you write a lot more tests and our tests would end up testing only one thing at a time. Having said that, I would say maybe half of my tests actually only have one assert. I think it only becomes a code (test?) smell when ...


81

The only advantage I can think of for inline tests would be reducing the number of files to be written. With modern IDEs this really isn't that big a deal. There are, however, a number of obvious drawbacks to inline testing: It violates separation of concerns. This may be debatable, but to me testing functionality is a different responsibility than ...


75

new CloudService() And there's your problem. Modern OO design recommends that this sort of dependency be passed in rather than constructed directly. This can be passed into the function itself, or to the class at construction time. It could also be grabbed or aggregated by an Inversion of Control container if that sort of complexity is warranted. At that ...


73

It's a matter of definition. A test with dependencies is an integration test, not a unit test. You should also have an integration test suite. The difference is that the integration test suite may be run in a different testing framework and probably not as part of the build because they take longer. For our product: Our unit tests are run with each ...


73

The hardest part of doing unit testing is getting the discipline to write tests first / early. Most developers are used to just diving into code. It also slows down the development process early on as you are trying to figure out how to write a test for the code. However, as you get better at testing, this speeds up. And because of the writing tests, the ...


67

In general, I would avoid it. If your private method is so complex that it needs a separate unit test, it often means that it deserved its own class. This may encourage you to write it in a way which is reusable. You should then test the new class and call the public interface of it in your old class. On the other hand, sometimes factoring out the ...


66

Be concerned. You write unit tests to prove your code acts the way you expect. They allow for you to refactor quickly with confidence. If your tests are fragile, difficult to understand, or if they are difficult to maintain, you will ignore failing tests or turn them off as your code base evolves, negating many of the benefits of writing tests in the ...


66

When you write one test, you concentrate on one thing. With many tests you spread your attention on many tasks, so it's not a good idea.


65

Are unit test smells important? Yes, definitely. However, they are different from code smells because unit tests serve a different purpose and have a different set of tensions that inform their design. Many smells in code don't apply to tests. Given my TDD mentality, I would actually argue that unit test smells are more important than code smells because the ...


63

Let me begin by thanking you to share your experience and voicing out your concerns... which I have to say are not uncommon. Time/Productivity: Writing tests is slower than not writing tests. If you scope it to that, I'd agree. However if you run a parallel effort where you apply a non-TDD approach, chances are that the time you spend ...


62

In many ways I agree with your team. Most unit tests are questionable in value. Since the vast majority of tests seem to be too simple. It is much harder to write good testable code than just working code. There's a large percentage of the developer community that believes in just get it to work, versus code/design quality in itself. And an even larger ...


61

I will personally not write unit tests for situations where: The code has no branches is trivial. A getter that returns 0 doesn't need to be tested, and changes will be covered by tests for its consumers. The code simply passes through into a stable API. I'll assume that the standard library works properly. The code needs to interact with other deployed ...


60

Imagine that you had a suite of tests that could run in an eyeblink and would light up a green or red light. Imagine that this suite of tests tested everything! Imagine that all you had to do to run the suite of tests was to type ^T. What power would this give you? Could you make a change to the code without fear of breaking something? Could you add a ...


59

Looking at the other answers here, I think there might be some confusion between static methods that hold static state or cause side-effects (which sounds to me like a really bad idea), and static methods that merely return a value. Static methods which hold no state and cause no side effects should be easily unit testable. In fact, I consider such ...


58

While tests are a good idea, the intention was for the original coder to build them as he was building the application to capture his knowledge of how the code is supposed to work and what may break, which would have then been transferred to you. In taking this approach, there is a high probability that you will be writing the tests that are least likely to ...


55

If you've ever seen the benefit to writing a main method to test some small piece of code for school, unit testing is the professional/enterprise version of that same practice. Also imagine the overhead of building the code, starting your local web server, browsing to the page in question, entering the data or setting the input to the proper test seed, ...


53

I have never thought that more than one assert was a bad thing. I do it all the time: public void ToPredicateTest() { ResultField rf = new ResultField(ResultFieldType.Measurement, "name", 100); Predicate<ResultField> p = (new ConditionBuilder()).LessThanConst(400) .Or() ...


51

If you don't include the unit tests in the checked-in source code, then: how is someone who downloads and builds their own copy of that code going to verify that it's working the way it was intended? Compiler and library bugs are rare, and data errors (particularly ones that don't render the source code impossible to compile) are even more rare, but they ...


50

Tests should fail for one reason only, but that doesn't always mean that there should be only one Assert statement. IMHO it is more important to hold to the "Arrange, Act, Assert" pattern. The key is that you have only one action, and then you inspect the results of that action using asserts. But it is "Arrange, Act, Assert, End of test". If you are ...



Only top voted, non community-wiki answers of a minimum length are eligible