Type of Projects where Unit Testing is useless [closed]

Answer 1

"... it's a lot of unnecessary and time consuming setup work, like stabbing out all the calls to a database and mocking business objects, etc. when at the end all you need to know if something happened to the DB."

Sounds like you're testing the wrong thing.

Why stub out database calls? Why not create a test database and test the actual database calls against that test database? [That's the way the Django testserver works, and it is great.]

Why mock out the business objects? That's what you're testing, right? It's okay to say "we assume the ORM works" and declare your "unit" is the business object + ORM + database. Test that, since that's where the questions arise.

Unit test the things you wrote.

The things you downloaded should have their own unit tests.

Unit tests can come in layers -- you can write integration-like tests that assume that the ORM layer already passed all of its tests.

Answer 2

I've never really came across a strategy for unit-testing the view layer of the application that was worth the trouble.

I'd love for someone to prove me wrong about that, though.

Answer 3

I am working on a software that interfaces with a production machine (using some industry standard as the communication protocol). As a result, most methods of the communicator class are triggered by messages from the machine, they are never called from the outside. So I made them private.

If I want to test this functionality, I need to create a simulator that simulates the machine behaviour, in order to run some black box tests on this class. Building the simulator would probably take at least 50% of the time I needed for the communicator.

I would have made the functions that are triggered by the machine public, but that started some very heated arguments in our team...

Answer 4

To answer your question, there are definitely some exceptions.

In fact, I'd say the usefullness of automated white-box testing is more likely the exception rather than the rule.

It takes extra time, the tests have to be rewritten anytime there is significant change, slowing down and hindering development. Also, just becuase your tests pass is no guarentee that your app is working correctly or solving the problem it is intended to for users.

White-box testing with automated tests has been a tool in the toolbox for awhile--lately for some reason it is all the rage, and if you speak out against it you are ostracized to a degree by TDD zealots.

Better to understand it, and use it where it could be useful. For example, a friend of mine was an SDET on the Microsoft Frarmework team -- this was a gerat example of where TDD was a great asset. That is, they were developing the engine for a development environment to be used by millions of people.

For your run of the mill web app, even enterprise level, I would be skeptical that such rigorousness is worth the added time and complexity. However, if you have a key component that will be used/re-sued extensively, it could be worth it for those pieces, etc.

Answer 5

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

This person is a danger to his or her self. Remove them from the code immediately.

Answer 6

I would say that as soon as you make a first function in your project, you need a unit tests for it, period. If your codebase consists purely of side-effect code, like the shell script, for example, you can do other types of automated tests, but if it's not some throwaway code like Esko Luontola described, you better write any automated tests than end up with none.

However, in some areas of the complete application there's no automated tools to do the check for you. GUI and everything that renders on screen is one example, as even Selenium don't have the interface to automatically check whether the modal window appearing animation really does play and is not glitchy. You must use a real person to manually test this stuff, and it's the reality of proper QA.

You PDF example is flawed in the sense that there's no notion of what feature set do you want to test in the PDF generator. If you need to be sure that the already checked data will be present in the resulting PDF, you can even do something absolutely blunt like grep through the file searching for that data, because PDF is nothing more than a text file with binary blobs for images in it, which you can safely skip in this case. If you need to be sure that the formatting is right, then currently there's no way to automate it, so you test it manually.

In the CRUD example, you do not stub the 3rd party ORM tool. You write a wrapper around it, because in next 2 years ORM tool either will be replaced by something more sparkly or just receive some BC-incompatible update. You then write the fullstack integration tests specifically for this wrapper, to be sure it does what your application needs, and then mock the wrapper in all other tests to prevent them to be dependent on the runtime environment. Both of these types of tests are crucial in preventing regressions and supporting you in refactoring.

In conclusion, I should note that if you care about your resulting application at all, you will test the validity of the functionality anyway. Point is, to test the application manually each time is a nightmare leading to almost no testing at all. So you need the automated tests. And to get the best feedback you want these automated tests run as often as possible, ideally constantly. For it, you need them to be crazy fast. And for automated test case to be crazy fast, there is no solution better than to test only the stuff relevant to this case. So, we ended with the the unit test definition, and did it naturally.