Type of Projects where Unit Testing is useless [closed]

Answer 1

• For example writing automated tests for the user interface/presentation layer is often not worth the trouble. In that case it's often best to keep the presentation layer very thin, and have a testable layer which contains all the functionality of the presentation layer. Then the presentation layer will be mainly declarative and contain only simple glue code. When everything is declarative, there is little that can break, so testing it is not necessary. Things such as are the UI elements aligned properly, is the layout ok, are the labels right etc. are easier to test manually.

• Throwaway code. If the code will be used only once, and it is not important that it works right, and if ever the need to modify the code arises you can afford to rewrite it, there might not be benefit from writing high quality code and tests. But when the code gets bigger, or you need to maintain it, or it is important for the code to work right, writing tests is worth the effort. I once heard somebody say that if he writes more than 10 lines of code without tests, then he begins to be unsure whether the code he just wrote will work right.

Answer 2

Please don't conflate unit testing (UT), which is a tool, with test-driven design (TDD), which is a methodology. see this for more

Also, remember that one of the benefits of unit tests is for regression testing, i.e. as insurance against future breaking changes (and to help verify that fixed bugs do not become un-fixed).

In your first example, I would unit-test the PDF conversion as follows:

• start with a known set of sample data, and generate the PDF document
• manually verify that the generated PDF is correct
• retain the sample data and correct PDF document as part of the test suite
• write a function to compare two PDF documents for differences (at the binary or content level, as appropriate)
• automate this unit test to compare the PDF document generated from the sample data with the verified-correct document from the first step

Now, whenever you change the PDF generation code, you have an automated unit test to verify that you did not break document generation at least for the sample data and output format.

I have used the same technique for verifying HTML-rendered pages, GUI screens, etc. Manually verify the baseline, then automate the comparison after that. This provides insurance against future breaking changes.

Of course if your output formats change frequently this may not be as useful, but a baseline test of the basic output formatting is likely to have a long lifespan.

In your second example it sounds like you would be testing the 3rd-party ORM tool, which is probably pointless. However, again some baseline tests may be useful as insurance against future breaking changes, depending on how you are using the tool. For example, instead of mocking up the entire n-tier chain (I'm not a fan of mocking when it is not necessary), just use the ORM tool to create, read, update, and delete a typical object/record, and verify the operation using direct SQL statements on the (test) database. That way if the 3rd-party vendor later updates something that breaks the basic functionality you'll know about it, and new developers to your project can easily see how to use the ORM tool from the unit test examples.

Answer 3

If your code is going to be reviewed or used by someone else then it should be tested. If not at a class level, then at some higher level. I hate when people send their code out for review when it is obvious that they didn't take the time to bother that it works (or worse yet doesn't even compile).

I seldom find unit testing (at class level) of any value. I can easily do that kind of testing by walking through the debugger when I'm developing the code. I prefer to test classes that are supposed to work together as a unit. I get way more bang for the buck taking this approach. After all, I don't really care if functionX does exactly what I think it is supposed to do when it is by itself, but doesn't do what it NEEDS to do when working with the other classes in the system.

Answer 4

Unit Test could be part of the QA process but it shouldn't be the whole QA process.

In general, Unit test is used as:

a) some QA uses only Unit test and those processes usually miss a lot of troubles that can't be tested automatically. For example (and it is not so strange), lazy QA guys that ask a ready made unit test then they can input some values and call it a day.

b) Other QA uses as a compliment of other test. However, i trends (always?) to be redundant.

So unless the Unit Test is painless (specially about to not to add or modify the code) then, old-school-testing is the solution (that in any case, manual testing should be done).

Answer 5

I'd say never, simply because people may already have a tendency to perform less unit testing than necessary. If we say "unit testing may not be necessary" then we open the door for all kinds of excuses...