Stack Exchange Network

Stack Exchange network consists of 175 Q&A communities including Stack Overflow, the largest, most trusted online community for developers to learn, share their knowledge, and build their careers.

Visit Stack Exchange

Hot answers tagged

409

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


250

There are two things you can test in difficult-to-test code. First, the degenerate cases. What happens if you have no elements in your task array, or only one, or two but one is past the due date, etc. Anything that is simpler than your real problem, but still reasonable to calculate manually. The second is the sanity checks. These are the checks you do ...


241

If I have a fairly complex object with a complex method, and I write my test and the bare minimum to make it pass (after it first fails, Red). When do I go back and write the real code? And how much real code do I write before I retest? I'm guessing that last one is more intuition. You don't "go back" and write "real code". It's all real code. What ...


213

The difference between BDD and TDD is that BDD begins with a B and TDD begins with a T. But seriously, the gotcha with TDD is that too many developers focused on the "How" when writing their unit tests, so they ended up with very brittle tests that did nothing more than confirm that the system does what it does. BDD provides a new vocabulary and thus focus ...


195

That's ridiculous. TDD forces code to pass tests and forces all code to have some tests around it. It doesn't prevent your consumers from incorrectly calling code, nor does it magically prevent programmers missing test cases. No methodology can force users to use code correctly. There is a slight argument to be made that if you perfectly did TDD you would ...


176

Yes, with 100% coverage you will write some tests you don't need. Unfortunately, the only reliable way to determine which tests you don't need is to write all of them, then wait 10 years or so to see which ones never failed. Maintaining a lot of tests is not usually problematic. Many teams have automated integration and system tests on top of 100% unit ...


118

Should savePeople() be unit tested? Yes. You aren't testing that dataStore.savePerson works, or that the db connection works, or even that the foreach works. You are testing that savePeople fulfills the promise it makes through its contract. Imagine this scenario: someone does a big refactor of the code base, and accidentally removes the forEach part of the ...


115

In regard to the common definition of unit tests, I'd say no. I've seen simple code made convoluted because of the need to twist it to suit the testing framework (eg. interfaces and IoC everywhere making things difficult to follow through layers of interface calls and data that should be obvious passed in by magic). Given the choice between code that is easy ...


106

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


104

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


103

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


89

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


85

Software is not a house. Intuition is good, but understand that it isn't always correct. Break down all the specs into inspection I think I will need (see into the future). This isn't accurate. In TDD, you're describing how you want to use the code. The specs say "There must be a house, with a way to enter it." The test then says "Hey, I want to have a ...


83

A lot of the examples I've seen of tests get down to the minutiae, covering all facets of the code. So? You don't have to test everything. Just the relevant things. Since I'm the only developer and I'm very close to the code in the entire project, it is much more efficient to follow a write-then-manually-test pattern. That's actually false. It's not ...


83

One of the benefits of a TDD approach is only realised when you also do emergent design. So in your first analogy, you wouldn't write 100 tests, as there's no possible way that you'll know what your software will look like. You write one test. You run it. It fails. You write the smallest unit of code to make your test pass. Then you run your test again. It ...


80

I used to write tests for scientific software with difficult-to-predict outputs. We made a lot of use of Metamorphic Relations. Essentially there are things you know about how your software should behave even if you don't know exact numerical outputs. A possible example for your case: if you decrease the amount of work you can do each day then the total ...


78

Regression testing It's all about regression testing. Imagine the next developer looking at your method and noticing that you are using magical numbers. He was told that magical numbers are evil, so he creates two constants, one for the number two, the other one for the number three—there is nothing wrong in doing this change; it's not like he was ...


77

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


76

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 break-detect-debug-...


76

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.


75

Of course you can have private methods, and of course you can test them. Either there is some way to get the private method to run, in which case you can test it that way, or there is no way to get the private to run, in which case: why the heck are you trying to test it, just delete the damn thing! In your example: Well, it's possible for me to make an ...


73

Suppose you have class called "ledger" a method called "calculate" that uses a "Calculator" to do different types of calculations depending on the arguments passed to "calculate", for example "multiply(x, y)" or "subtract(x, y)". Now, suppose you want to test what happens when you call ledger.calculate("5 * 7"). The London/Interaction school would have ...


71

Unless you are going to write code without testing it, you are always going to incur the cost of testing. The difference between having unit tests and not having them is the difference between the cost of writing the test and the cost of running it compared to the cost of testing by hand. If the cost of writing a unit test is 2 minutes and the cost of ...


68

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


68

Is writing testable code still good practice even in the absence of tests? First things first, an absence of tests is a way bigger issue than your code being testable or not. Not having unit tests means you're not done with your code/feature. That out of the way, I wouldn't say that it's important to write testable code - it's important to write flexible ...


67

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


66

This (Clojure author) Rich Hickey interview contains the following. I feel 100 % sympathetic: Life is short and there are only a finite number of hours in a day. So, we have to make choices about how we spend our time. If we spend it writing tests, that is time we are not spending doing something else. Each of us needs to assess how best to spend our time ...


66

A lot of people think that unit testing is method-based; it's not. It should be based around the smallest unit that makes sense. For most things this means the class is what you should be testing as a whole entity. Not individual methods on it. Now obviously you will be calling methods on the class, but you should be thinking of the tests as applying to ...


65

If you have worked on large code bases created using Test Driven Development, you would already know there can be such a thing as too many unit tests. In some cases, most of the development effort consists of updating low-quality tests that would be best implemented as invariant, precondition, and postcondition checks in the relevant classes, at run-time (i....


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