Purposeless unit tests are a waste of time. These are tests against your compiler or external frameworks. For example: @Test testAddUser() {assertNotNu

Purposeless unit tests are a waste of time. These are tests against your compiler or external frameworks. For example: @Test testAddUser() {assertNotNull(new User("columbo").save())} Wahoo! the ORM works! The biggest problem I have with unit tests is they tend to be a) just testing frameworks (crud) and not much else b) so heavily built on mocking that changing them is like redesigning a wool sweater. These tests tend to examine how the code was written, not necessarily what the expected output is (oh shoot, I need to mock up five more objects to make this test pass... hey look at that, this test doesn't even check what should be returned. Nice) c) there is no context into or out of the unit test. The assertions are vague, it isn't clear how I got there, it isn't clear where I'm going (testXMLOutWithInProgressUsers ... what is the xml for, who are the in progress users... what is next in this chain of events) d) the things that REALLY need unit tests don't have them because they are too complex to write (ah, that whole system that runs a nightly bash script, takes in a stack of csv files from the client and converts it in our database... yeah, that's not tested). With all that said, tests are invaluable, but they need to actually, you know, TEST something. I like nodejs in that respect. It takes me seconds to fire up the webserver and test the rest api. I don't mock objects, I pass values directly through the api and check the expected results. I like this because it shows the next user what the api actually looks like and I'm testing the full stack (In my experience controllers are notoriously undertested, mainly because you need the full stack running). Since the application is really just an api this means that I'm able to test everything equally, from batch processes to CRUD.