Tag Info

Hot answers tagged

345

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 ...


199

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() { ...


123

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 ...


112

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 ...


111

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.


110

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 ...


101

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). ...


96

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 ...


90

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 ...


89

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 ...


83

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 ...


80

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 ...


70

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

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 ...


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

Great question. 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 1 assert. I think it only becomes a code ...


65

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 ...


62

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 ...


61

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 ...


58

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 ...


57

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 ...


57

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 ...


57

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 ...


56

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 ...


54

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, ...


50

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

TDD is used mainly (1) to ensure coverage, (2) and to drive maintainable, understandable, testable design. If you don't use TDD, you don't get guaranteed code coverage. But that in no way means that you should abandon that goal and blithely live on with 0% coverage. Regression tests were invented for a reason. The reason is that in the long run, they save ...


48

Tests are there to ensure that you don't (re-)introduce problems. The list of failing tests isn't a substitute for a bug tracking system. There is some validity in the POV that failing tests aren't only indication of bugs, they are also an indication of development process failure (from carelessness to badly identified dependency).


48

Short Answer: Absolutely positively. Long Answer: Unit tests are one of the most important practices I try and influence at my place of work (large bank, fx trading). Yes they are extra work, but it's work that pays back again and again. Automated unit tests not only help you actually execute code you're writing and of course verify your expectations but ...



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