That seems very unproductive. Every time you make a trivial change you would have to wait 8 hours. I'm sorry, but manually testing your change is going to be much faster. You make it sound like that any change can break any part of the codebase. In reality a change is going to only effect a localized section of your code. It's not like fixing a font rendering issue is going to break your networking code.
A. The project is complex. B. It's not written in a way you can write tests meaning that you will have to spend a long time creating proper mock objects for potentially hundreds of different objects.
Nigger I work with thinks that asserts exist to verify conditions on user input. He's an okay idea guy (has not entirely shitty ideas), but sometimes he just throws shit at everyone with the code he writes.
OP It can be helpful. I have found stupid mistakes in my code from the brain-dead tests written for it. The problem is that a good bulk of unit tests are written for code that is trivially correct. That 80/20 or 90/10 rule: 90% of bugs are in 10% of code, which means that 90% of unit tests cover code that is statistically unlikely to be incorrect.Most bugs peek their heads when you start integrating the pieces together and find that somebody assumed something that wasn't true.
Example from nigger I work with: A) Read in information B) Validate information C) Do some transformations D) Report validation errors and prompt to continue with invalid data Nigger I work with was working on step C, and decided that since validation had already been done, that he would never get a NULL pointer and didn't have to check for one. The requirements are that the program can continue with invalid input, a requirement he disagreed with. All the little pieces work as tested, however the full stack mysteriously crashes. His defense: "Is that so? I didn't know that that was a requirement! I didn't notice that every other function around the one I modified checks for NULL pointers."
Dylan Young
Outdated methodology; the good parts such as iterative development and acceptance testing-as-living-documentation are better implemented in BDD for large organizations, because all stakeholders can read the tests (not just the devs) and automated testing is put in reach of non-programmer analysts, making better use of everyone's time. For smaller projects, it's overkill. There's just no use case for it.
Adam Reyes
my company has the ttd mandate (I don't know what else call it) buy nobody does that in reality, tests are written afterwards and it's just natural. I agree 100% with Torvalds on tests in code
But linux has the benefit of not having deadlines and the need to sell the product, unlike 5he corporations. They hire such code monkeys you literally cant go without tests. And such bullshit like TTD was invented because of that (just like java)
Jacob Flores
I also hate that all of our code has all the methods virtual just so they can be mocked in the gay Google test and it's just to check if a function is called.
void func1 () { //do something in this function func2 (); // virtual just so you can check if it was called in your UT }
Jackson Martin
Tell that to the NT kernel developers.
Luke Robinson
You're almost certainly doing something wrong. Either write a preprocessor macro that automatically makes a mockable function, or get hardcore with your test suite and have it look at debugging symbols to find out of a method got called.
Aaron James
I suggested the debug symbols approach but got turned down. This is not my own code, Jesus Christ user...
