There is a bit in Crytopnomicon about a guy who went blind because he blew his monitor up in his face messing with "minux" settings. Weren't there very scary warnings in X11 config files for a while?

There were, yeah, but I think the fear was somewhat overblown. I had totally forgotten about the bull**** with video mode timings. I did actually have to fool with that recently, though... I have a small 4" display meant for use with a raspberry pi. It has a very non-standard resolution, to get it to work you need to add both a special X11 stanza and I had to do something else, I don't remember what now, to get text to work at boot time. Something in the grub config probably.

I just bought my son a monitor for his own computer, which he uses to play games and do school stuff. Prior to this he just used our enormous/awesome television. The monitor is perfectly nice, but not high end. It's a 27" high resolution screen.

It so thoroughly destroy what I had when I was 20 that it's hard to fathom. Back then I spent $1000 on a 21" Sony Trinitron. I think it could do 1600x1200 resolution but you should expect terrible refresh rates, ghosting, illegibility, etc. Part of me rebelled at giving him this incredible jewel, like, dude, what did you do to deserve this thing? When I was his age I programmed using a 80x24 green and black text only monitor.

But it's 250 bucks, so...

I just spent 2 hours trying to figure out if somehow keepalive was broken or partially broken for our site, but have come to the conclusion that my testing tool was broken (or lying). So that's nice.

Went in to work today for the first time in 3 months. Holy crap how do you people put up with rush hour commuting? Worst 29 minutes of my day.

Live an 11 minute walk away.

You guys ever feel ashamed of your pile of **** code?

Got a massive PR about to be merged. This is the same PR that I pair programmed with my coworker Turtle. No longer pair programming and now I have spent the whole week fixing bugs and writing tests. Code coverage is hovering at 40% today. Really want to get it above 70% and then have Jenkins prevent any PRs from being merged if they are under that threshold.

Code coverage is a good general guideline imo but focusing on it too much is bad. A few good tests are better than a bunch of useless tests.

IE - if you know a bunch of stuff will absolutely break when the app boots if it's not coded correctly - not really that important to test. However if you need to handle a rare back-end 500 error a certain way - that is a very valuable test because it won't show up in normal app booting, nor in normal smoke testing.

Also what do you expect pair programming with this guy?

I agree, and so does kent beck. even more, the idea of 100% coverage is a total illusion -- mathematically speaking:



-- from Why Most Unit Testing Is A Waste

The TLDR is that tools that report coverage tell you if every line, or every method has a test, which is a silly arbitrary metric for correctness because to test correctness you need to test every possible path of execution, of which there are exponentially many.

That said, I don't think unit tests are a waste at all, but you need to be honest about their benefits and not fool yourself into a false sense of security. I like the kent beck conception of unit tests are "insurance bets"... you are taking out insurance on various things that could go wrong, and each bet has a cost (writing the test and maintaining it) and a benefit (catching a bug either now or during a later change). Which means, and as suzzer points out and experience makes obvious: Some things need insurance more than others.

Also, for me, the largest benefit of unit tests is that they force you to decompose your code in a testable way, and doing that correctly will usually force you into a better design, because there is a deep synergy between testability and good design

Perfect timing for this. I've been tasked with writing unit tests for the current contract, and I'm trying to figure out how to explain it's too early.

I'm a little critical of unit testing. I think a well written function is, more or less, like writing a mathematical proof. If you solve for case x and x1, you generally have solved case x2 and so on.

With that said, if I can somehow use testing to promote better code across the system, I'm all for it. Problem is this code base is under considerable flux, and everything is a god function or class. Basically, I'm not sure if I can write tests without massive refactoring.

Back end unit tests: seems fine go nuts. Front end unit tests (specifically enzyme) : giant waste of time that typically takes longer than the actual development.

Do you mean Think UNIX? It looks good.

https://www.amazon.com/Think-UNIX-Jo.../dp/078972376X

Weird, I'm a big fan of test driven development. I don't even mean really trying to find all the tricky edge cases off the bat, but, a test can be a good way to define what the function is supposed to do. You work at it until it passes the test. Sometimes along the way you find that your initial conception of what the function should do is wrong.

I think this is usually a faster way of getting something working than trying to integrate it into it's position first.

I also think of it as future protection more than current correctness. It's usually not too hard to satisfy yourself that a function is correct when you make it. You're probably wrong, but not that wrong. But in a year when you (or someone else) needs to refactor, it's nice to know that it still works "the same" to some degree of certainty.

Certainly, I have been able to make *huge* structural changes to our product without hiccups because tests caught most of my logical mistakes early in the development phase.

Yeah, the problem is that there is variable input and variable output representations. I can write a test at 10am that is no longer valid at 5pm because a data structure has some field added to it (and I wouldn't know about it). And also, the codebase... needs work.

You are correct

We started writing acceptance criteria in the form of bdd stories and I liked that, defining a feature by how you?ll verify it seems more concrete than saying it will be ?responsive? or ?performant? or other feels.

Yeah I'm a big fan of BDD and TDD as well. But you need a place that's fully committed to it, and I've never worked at one of those.

Also you need some kind of reasonable mock data structure - which is a challenge on a monster site that gets all its data from a myriad of back end services which are out of your control.

This is true. And making your own mocks is a huge mine field. The biggest mistake of my professional career came from a mistake I made in mocking an external data source. We're talking I had to give a mea culpa to the board of a place I worked at.

I was making a system that managed what is called "shortability", which is to say, if you want to short a stock, you have to borrow it, then sell that, and then later buy it back and return it to the person you borrowed it from. If you can demonstrate that a stock is really easy to borrow, then they'll let you skip the borrow part and pretend that you did. So I wrote a system that maintained a database of the shortability of various stocks. Worked fine.

When we moved to deploy it to europe, I knew I'd have to handle the fact that the SAME stock can trade under different symbols in different euro markets, but be fungible between them. Like, I can borrow as symbol X from the irish market and sell as symbol Y on the german market.

I thought I knew how the market and currency information was delivered, and made a mock database for testing. The real database would be delivered from a 3rd party daily.

Well, I was wrong. So the system refused to start up in the morning. The european morning, i.e. like midnight for me. They woke my ass up in the middle of the night, I had to really hurridly fix it, and then explain to a bunch of suits why I thought it was OK to put their millions of dollars at risk.

We have some jest/enzyme tests with generally poor test coverage on the front end.

I never have the motivation to write tests vs work on new features. Like everywhere, we are trying to get as many features delivered as possible so I keep telling myself I'll go back and write tests when we hit a feature freeze in a month and do bug fixing before release. Well see if I do.

We have a suite of what we call "end to end tests" which are basically... put up a full stack and run the UI through it's paces. It takes a Very Long Time to run, doesn't really cover much, and fails a lot. I am not a fan.

We have a zillion "unit" tests and "integration" tests that would take something like 3 hours to run if we didn't parallelize. As is they take like 30 minutes and fail like 20% of the time due to order of operations or bad cleanup between tests. Still haven't been quite about to track down why this is happening.

A huge chunk of the tests have no value and most tests are poorly written so that they're far slower than they should be.

Several devs I work with just think on the level of you need code coverage and it drives me insane.

If history is a guide, you won?t. Too busy to do it right the first time rarely changes...

Yeah at our place there's a Selenium team. Keeping the tests working is a full time job for them. They also take a long time and have to be run twice due to such high failure rate. Only if the test fails both times is it marked failure. I think it takes 12 hours to run 2 passes of the entire suite.

Also they do stuff like key on CSS classes or IDs that we inadvertently break all the time. Further compounding the problem - our back end data is constantly changing stuff like tv schedules and our test users only last a few days before they break, and it's a gigantic PITA to create new test users in the myriad of back end systems (which we don't control) needed to run properly.

It's very hard to write specific tests in such an ephemeral environment. You either wind up with tests that constantly need to be curated, or tests that are so vague they pretty much just confirm a page loads.

It's always fun when some new group comes in all pumped up about some new e2e testing technology - and I get to burst their bubble that no matter what the technology, keeping the tests running will be a full time job for several people. You can see their hearts sink. Heh.

I spent many months of my life beating my head against the wall trying to get protractor (angular-aware alternative to selenium) tests stable. Gave up.

We also have this weird bug in our karma unit tests where only in the CI/CD environment they show call stack size exceeded. It's some kind of weird race condition, but exacerbated by the fact that apparently the max call stack size is lower on RHEL 6.5 than it is on our local PCs or macs.

I spent a week trying to debug that on the RHEL server, never could identify which test was causing it. It's some kind of cumulation of tests, because removing one at a time doesn't solve the problem. But removing half does. Nor could I figure out how to raise the call stack size on RHEL or lower it to recreate the problem on my local machine. Painful.

And basically all of this was my personal quest to avoid the devs just commenting out unit tests until the problem stops. No one else at the company cares - as long as they can still say they have testing as part of CI/CD. They basically shush me when I try to bring up that our testing barely works. I suspect it's this way at a lot of big companies. Unless you have a testing evangelist at the director-level holding everyone accountable, the tests go by the wayside in favor of meeting deadlines for features the business actually cares about.


tl; dr: testing, sounds great in theory but hard to work at big companies, especially if execs only care about saying they have testing

related to my earlier post: while politics certainly plays a role as you said, the other reason it doesn't work is that if your system isn't designed well, it will be almost impossible to write reasonable tests for it (read: tests simple and reliable enough that people actually want to use them). and good design is hard.

so what happens is people have this crappy system, then decide to make a concerted effort "to add test coverage," and ofc the tests they write end up being convoluted and brittle, and then the team throws up their hands and says, "this testing **** is a scam"

Yeah agreed it has to be designed to be testable from the beginning.

Even for e2e tests you need to agree on element IDs or some other identifier that doesn't change. Of course that becomes a problem when requirements change - and something that was unique is now repeated in some form on a page. Which is why we generally try avoid IDs in our HTML. But of course that makes it harder for the e2e test team. Cat chasing its tail basically.

Too early or too late?

This sounds nice but this is not how software engineering on planet earth works. Like I said earlier, engineering is about edge cases and testing is about when deductive reasoning does not apply or fails completely despite best efforts. Feel free to attach proofs to your code that prove that your code works but until you're prepared to write actual proofs, you need tests and lots of them.

It's possible you're too late. Are you tasked with writing unit tests or just automated tests? It sounds like the system needs end-to-end tests - it's rare that adding unit tests at this point in the development cycle is useful for the purposes of reducing defect rates IME. It's mostly useful for showing that the design is ****ed.