Why to engage into using Automatic Testing | Hacker News Reader

Why to engage into using Automatic Testing

cookingsource.wordpress.com

9 pointsipedrazas8 comments

If you are hired to write code, that's the contract; your job IS to write code. Just like a plumber's job isn't to solve problems in general, just the problems involving plumbing, and that's what makes him a plumber instead of something else. Otherwise, there is no reason why we would call them plumbers, why they would get specifically educated in plumbing, and bring a plumber's toolbox. You don't call the plumber when you want a sandwich or a car repair. A plumber who lets clients jerk him around by having him make them sandwiches or answer their phones doesn't know his business.

If you are a plumber, please don't tell me that you offer solutions. Please tell me you are a plumber so I don't have to get confused about what it is you are actually offering.

> If you are a plumber, please don't tell me that you offer solutions. Please tell me you are a plumber so I don't have to get confused about what it is you are actually offering.

This is a classic case of what happened in the pest termination industry. You have two types of terminating companies: the solution-based (a.k.a. recurring revenue) companies, and the one-shot companies that you pay to come kill the pests in your house. There's room in the world for both, depending on your specific desires and needs when you see a roach in your bedroom.

I really have never seen a contract stating “coder” or anything similar. It always have something else, referring to the domain of knowledge they expect from us. For me that’s the important thing, coding is just the tool. In my case I love working making games, so if the current way for that were screwing things together I would happily be called Games Screwdriver.

I think we both agree in most of the terms. Maybe I should have expressed myself better in the post. I meant to say, solve problems in the domains we have knowledge about. I’ll update it in the post. Thanks for your feedback

I don't think this analogy is useful. I think understanding the why is important. The plumber knows why you want running water, has seen many homes with water systems similar to yours, and almost certainly owns a home himself. But introducing software into someone else's business has no such guarantee of familiarity. There has to be a discovery process, where you choose between several ways to fulfill the need, with a much larger problem space than home water systems. In my experience, a large part of software is automating processes, and I can't imagine replacing a process properly without understanding why it is done in the first place. Business owners can understand a problem at a high enough level to hire people to solve it, but software engineers in that position have to understand a problem so well that they can describe it to machines who will take every step at face value, executing it unthinkingly. Encoding a bit of the why something is being done, even if it's just in manual tests of the software, has been crucial for that software to do the job properly in my (limited) experience.

I'm not being jerked-around being told to make sandwiches. I'm being told, the water-operated sandwich making machine is too slow/doesnt work properly. I might just as easily recommend a sandwich catering service, or pick up a manual on building fancy electric sandwich makers, as repair/enhance the water pipes.

Disclaimer: I'm a young software engineer who, perhaps naively thinks I will always be able to join interesting projects and learn new things while being treated like a partner instead of a technician. This has been my experience so far, but perhaps you reach a point where, having specialized, you churn out the same solution for company after company in a niche for efficiency reasons.

In my experience unit testing has less value than end-to-end testing. Unit tests rarely break and the reasons it break is not something that you couldn't guess. In contrast end-to-end tests fail with a big surprise! I always enjoy seeing my end-to-end tests catching errors that I would never ever thought of.

The down side of end-to-end tests is that it's slow to develop and slow to run. Because in many cases, end-to-end tests should be sequential and involves network calls and browser rendering. In general it's worth it.

I would say that it's more than that. End-to-end is the only test that reproduces a real case scenario.

I often suffered from that problem with unit tests - if you thought of writing the test, you could have written that case into your code, making it only really useful for regression testing. It doesn't help you discover bugs that are there that you didn't think of. Integration testing helps with that because you test multiple parts together, which is hard to hold in your head and chances are you'll find problems you hadn't thought of while programming. But failing integrations tests can be tricky to diagnose the root problem, especially compared to unit tests, and require a lot of code to be written or stubbed before they can be used.

So, I've been trying to adopt "property" based testing where you test invariants of the output with pseudorandom inputs, a-la quick check in haskell. Big shoutout to http://jsverify.github.io/#jsverify :)

While it can certainly be hard to apply to problems or find some useful invariants, It's been enormously successful in finding bugs I didn't think of, and shrinking is an elegant solution to making failures more easily diagnosable.

Modern software development has always struck me as trying to optimize the wrong thing. It tries to make change easy, but changing things is never easy. Just throw away your code and start again. If this a lot of effort, its probably doing too much.

Reply on news.ycombinator.com