Is it normal to have tests that are way bigger than the actual code being tested? For every line of code I am testing I usually have 2-3 lines in the unit test. Which ultimately leads to tons of time being spent just typing the tests in (mock, mock and mock more).
Where are the time savings? Do you ever avoid tests for code that is along the lines of being trivial? Most of my methods are less than 10 lines long and testing each one of them takes a lot of time, to the point where, as you see, I start questioning writing most of the tests in the first place.
I am not advocating not unit testing, I like it. Just want to see what factors people consider before writing tests. They come at a cost (in terms of time, hence money), so this cost must be evaluated somehow. How do you estimate the savings created by your unit tests, if ever?
You might be testing the wrong thing – you should not have different tests for every method in your code.
You might have too many tests because you test implementation and not functionality – try testing how things are done test what is done.
For example if you have a customer that is entitled to get a discount on every order – create a customer with the correct data and create an order for that customer and then make sure that the final price is correct. That way you actually test the business logic and not how it’s done internally.
Another reason is for big tests is lack of Isolation (a.k.a mocking) if you need to initialize difficult objects that require a lot of code try using fakes/mocks instead.
And finally if you have complicated tests it might be a smell – if you need to write a lot of code to test a simple functionality it might mean that your code is tightly coupled and your APIs are not clear enough.