solraph

I've come to the conclusion that the idea that "unit tests" should test functions/objects in isolation with completely mocked dependencies is based more on the slow speed of those dependencies in the past than what actually makes for good tests. Now that we have faster computers and storage devices, and easy/fast store creation, we should move past this.

Obviously, this is very dependant (no pun intended) on the dependency in question, but as a minimum, anything with SQL should have a test that hits a real SQL DB (PG in docker for example) at some point.

> Has anyone ever actually found this to be true?

Yes, but you have to have the right kind of test coverage, and that's the tricky part.

Yesterday, I refactored a bunch of functions that changed a bunch of unit tests. However, since we also have integration/system tests on that code, I'm confident that I haven't broken the code as a whole. Without those system tests, I would not have confidence that the change would be successful, and probably would not have refactored.

In another codebase that hadn't been touched for a year, as part of a feature change I refactored an SQL statement to what I thought was a more optimal design and immediately broke a bunch of tests. Based on that, I was able to understand the original intent of the SQL, and updated it in line with the feature change. I added test scenarios for the new feature, but left the existing scenarios as is.

Without those tests, would have broken the system in a subtle way.

Com port is a standard USB-B port and is compatible with but

https://www.telephonewreckers.com.au/power-shield-safeguard-...

My only complaint is the formfactor is about weird.

I have no love for Haskell or functional programming, but the problem here isn't FP per se, it's that they tried to jam it into Java.

Don't fight the language or framework. If you are using Java, write idiomatic OOP code. If you want to write FP on the JVM, then start writing Clojure or Scala. If the business won't let you write Clojure or Scala, then do it on your own time and/or change jobs.

Honestly, having literally had a scenario 20 minutes ago where I wrote a test for what I figured was absolutely trivial code, and having it _fail_ on me and pick up a bug that I hadn't considered (and this is not the first time this has happened) I would strongly suggest it's the latter.

Do your unit tests the output and side effects exactly, or do they just make sure the function returned without error?

Just because function/method/whatever has 100% coverage, doesn't mean you have tested all the potential scenarios.

All the time? No. Depressingly often, it is to escape a person and relationship they desperately need to be free of.

I know and am related to several people who are divorced. It was not hedonism that drove the proceedings, but exasperation and pain.

EDIT after further consideration: And even if it is - so what? What business of that is yours?

Yes, but actually no. Context is important here. If that code had been written six months ago or even a couple of weeks ago? Have at it. But, the OP states "My colleague has just checked in the code that they’ve been writing all week." then "It was already late at night (I got carried away)."

If spent all week on something, working out the all the details, checked it in at 5pm, and then came in the next morning to discover that someone stayed up rewriting it rather than waiting till the next morning to talk to me about it first, I'd be absolutely livid.

However, since my array is currently 4.4kw at 3 in the afternoon, a 2.5kw burst isn't a problem.

From my foray into audio app (quite a while ago, I admit), I imagine application support would be tricky as well.

In our case, we decided it was a worthy trade off in terms of developer feedback times on our python microservices, because most of the SQL there is INSERT only. In our golang services which do 90% of the interesting SQL, we spin up PG in a docker container.

I've come around on this. I used to mock the DB, especially when it was being used as a dumb store, and now I just recreate the DB in SQLite, and see the DB as part of the system being tested, rather than something to mock.

However, I think it's important to note that it wasn't until improved SQLite capabilities, SSDs (and sometimes docker if I really need postgres) all came together that this actually practical. Previously using an actual DB would have blown out my test runtimes by a factor of 10x.

> I also don't think unit tests bring as much value as integration tests. In fact, a lot of times unit tests are IMO useless or just make your code harder to change. The more towards testing implementation the worse it gets IMO, unless I really really care that something is done in a very peculiar way, which is not very often.

I see this a slightly different way. My concept of a unit (ignoring the article) has expanded to be what makes sense for a given test. This may be a class or set of classes where there's a well crafted set of inputs and outputs, but where there's a tricky set of inputs and outputs (anything involving date calculation for example) I'll often write a set of tests for just that function. I'd probably call all of these "unit tests" however.

To me, an integration test involves testing that disparate vertical parts of a SUT work together. I haven't seen many of these in the wild.

I like the concept, but I can see bad actors abusing the heck out of these headers in so many ways.

That said, I don't follow what you mean by "to test is business logic, not code logic." To me, that is a distinction without difference.

An income tax calculator in a (sane) tax system is essentially a set of pure of functions or classes. This is a perfect place for a unit test. I might have additional unit tests for sub components of the hairy bits, but it's still unit tests all the way.

Types however, are not a substitute for unit tests. No type system is going to tell me if my income tax calculator covers all the edge cases.

That's actually lower than what the USA is doing right now. "The US solar industry installed 6.1 gigawatts-direct current (GWdc) of capacity in the first quarter of 2023"[0]

That is approx 469 MW of power being installed every week.

[0]https://www.seia.org/us-solar-market-insight (first link I could find)

For example, if a CEO in a large org demanded that engineers are all available via phone for level 1 support calls to cut support costs - that would be stupid, because even two short calls a day is going to have a massive impact on those engineers productivity on building the product(s), followed by any of the half decent engineers leaving for other jobs shortly afterwards.

He might not lack intelligence, but a CEO unwilling or unable to understand the other people work in a different way to him /is/ stupid.

CEO is management, and (effective) management means well... managing the various people, resources, and other restrictions to achieve the goals at hand. Being pissy that people and the universe don't work they way they want is immature and/or incompetent.

That switch is probably a relatively niche item when compared to some generic TP-Link switch, and AU & NZ are basically the only countries to use the Type I plug. That means the production run for that switch is tiny - it's probably not even a full days run, which means the economy of sale is reduced.

On top of that, the middle man is probably distributing a tiny amount of these to each store, so they can't just pull out pallets from the shipping container and put them on a truck, individual items probably need to be pulled out and re-packaged. All this adds cost.

The people who care about and are tasked with maintaining a large long running code base.

> You wanted to apply what they taught you in uni, which was Java, to PHP.

Nope, that came after my time.

> Can't you booksmart idiots STFU for once and let people do the pragmatic and sensible approach? I earned good money with it and had fun doing so. Then 2010 the next generation of clueless devs enters the scene, polluting it with their nonsense.

Those OO & OOP principles are the pragmatic and sensible approach learned after cleaning up after "hipster" web "artisans". If we're going to throw around claims without knowing anything about the other person; you sound like the kind of dev who writes some code that works on the happy path, but is completely unmaintainable and non-extensible.

(But I know nothing about you, so I really have NFI, just like you have NFI about me and what I do)

God help us if it this project becomes the normal way of writing http go servers applications. Maybe at that point it's time to become an embedded rust programmer or a monk.

I did this with a consultancy a few years ago. I did some Symfony work for a client they needed help with, but there was an (honoured) agreement that after that I would never have to do PHP work ever again. After that I moved into Python & Golang work.

I work in a company/team that has this, and while we use Jira[0], it's effectively there to remember what we need to do for a given task/bug and ensure that two people don't work on the same thing. The use of Epics lets management & stakeholders see what is happening with a given feature without bugging us.

We don't have estimations, retros, or any of the other usual rituals, and it's amazing. If there's a mismatch of expectations or we need to hash something out there's Slack and Zoom. Someone volunteers to write up a card, and we're done.

The corollary is that we've had a couple of hires come and go who just did not have the skills and/or interest in being part of those conversations, and they did not last. I'm in two minds if this is the damage inflicted on them by years of managerial Taylorism, or that they just could not keep up with the rest of the team. I expect (but hope to be wrong) that once we expand enough to have actual juniors we might have to embrace some of the more ritual parts of agile.

[0] We use Jira in Kanban mode with a couple of text templates for the different card types (epic, story, bug), and none of the usual rules about what can be moved in and out of what column.

EDIT: complete->couple

Unfortunately, I have had that conversation plenty of times. The point is to have that conversation/argument once, make a decision on what it means for the team, and then move on.

> What if you’re working with a major language barrier in the team, and misunderstandings can be mitigated with processes?

Process is communication. It's a way of doing mass communication. Instead of explicitly communicating everything to everyone, a process is way of saying "when X happens, you can assume Y".

For example, if a card is in the Done column, you can assume the code is in version control, deployed to production and checked to make sure it didn't explode on impact.

Then, instead of explicitly communicating every single deployment, you only need to communicate the exceptions. (ie; the things that don't fit neatly into an existing process)

If you're working in a team that has a major language barrier, I don't see how having a process can mitigate the need to explain that process, nor how the exceptions can be communicated effectively.