In my experience, it's usually not the existence of unit tests themselves that's causing an issue, but that most of them are badly written. One telltale sign is when writing the unit test becomes overly painful (like too much code setting up mocks), it usually means that your class is not simple enough or has too many dependencies.
Proper unit testing also complements integration testing in that corner cases can be handled at the unit test level, therefore reducing the amount of integration test code which arguably is much more brittle, runs slower and more complicated to write.
Many unit tests are just written to test code, which is at best irrelevant. At worst your codebase is 2-3x bigger and more abstract than it needs to, where useless tests keep code alive and useless code keeps tests alive.
Test functionality, as close to the promises given to outside consumers as is feasible. Be it API or UI for other people/projects/services.
This is the stuff that needs to work (and thus often need to be stable). No-one cares whether a function deep down inside the code, used a part of the implementation of promised functionality works. Delete it if you can.
Only case where I'd support "unit tests" as typically practiced (small units, isolated functions/classes) is around core competence (defined as narrowly as possible). But then I'd argue that this functionality should be put into a library anyways, which is used by products codebases. And then the tests are tests for the functionality promised to the products.
I'm not arguing against writing integration tests, they are as important if not more important, as you've said. Maybe I've only seen badly written ones, but my issue was against integration tests that check for example if this ever so important, but hidden, flag is being set properly after an API call when that can be checked at the service level. Someone eventually decides that flag is unneeded, and a whole host of tests fail and someone has to dig several levels deep to figure it out.
I guess I shouldn't have used the word 'brittle', but this is what I was thinking of.
And of course, I think unit testing anything and everything is absurd and not a good use of developer time.
I don't think you can avoid meta-debugging. That is, debugging your asserts or tests that you hoped would detect bugs instead of being the bug. Sometimes because more realistic tests unveil a bug, sometimes (as in your example) because underlying code functionality has changed. This is unavoidable but also often enlightening. To my mind, it's even okay if most of your bugs are meta - because these are usually very fast fixes, and it probably means you have a lot of checks. But by the same token, I would agree with you that all such tests have to be well-written, not mailed in, for just the reasons you give. It's too easy to assume that writing tests is somehow a fairly trivial task. Until you end up debugging the test.
I've seen this too. Unit testing was mandated from on high and it's something developers never learned to do properly. My telltale sign is more than one logical* assert. A test should usually be only a few lines of code, a dozen lines should be all that's needed for 99% of tests.
*Logical meaning only test for one thing, not a single assert statement. So testing for null and testing if a value is set is fine, but testing if 10 values are set correctly is not.
If integration tests are brittle, then the integration is likely to be brittle. In my opinion this is something to fix, not workaround by testing lower down.
I'm doing the exact same thing! (quitting end of this month too). While I haven't decided to completely leave tech, I'm planning to do a couple of 3-month furniture intensive classes for my sabbatical this year. I'm also going to apply to the College of the Redwoods. It's kind of a moonshot though, given my limited woodworking experience, but I figured it's worth a try. What's the duration of your entire course?
I'd suggest finding a hands-on online course that gives you a tiny portfolio in the end. A lot of the fun with programming is seeing your work come alive and seeing all the projects you've completed. Assuming you haven't programmed before, I wouldn't go with buying a programming language-specific book to start since those can be pretty boring to go through. Books will start to be useful as you develop a lot more curiosity and want to fill in your knowledge gaps.
My friend's learning from the ground-up and he's using Code Academy (https://www.codecademy.com). If you're a little more serious about this, you could also look into Udacity's Nanodegree program.
I'd also recommend giving Code Academy a try in the first instance. It's free, there's no set up on your computer needed (it's all done through their website) and it guides you through.
It's how I started learning when I was trying to do it around my job, I eventually left to work on learning to code full time.
Wow. You've described exactly what goes in my head during parties. I've been better at faking it / being able to emit short bursts of real gregariousness, but I've never been able to completely get rid of the anxiety.
Even so, the GWT creators ended up recognizing the value of presentation markup and introduced the UIBinder system (HTML markup + XML for custom widgets), which arguably made my life a whole lot easier when I was working on a moderate-sized GWT codebase. It's definitely better compared to mucking around with Swing-looking code soup.
GWT-P takes this a step further with completely isolated layers (MVP) so that you can easily make permutations of your app bound to a Tablet, Mobile, and Desktop set of Views very easily. I've been using it a year now and love it.
That looks narrow-minded for those particular employers though. The leadership might have made a lot of questionable decisions, but I don't think that should affect the quality of the engineers from that company.
