There was a research paper that took a variety of weaker LLMs and randomly asked each one to generate the next word, and it actually turned out really well.
It’s even worse then: that means it’s probably a race condition and do you really want to run the risk of having it randomly fail in Production or during an important presentation? Also race conditions generally are way harder to figure out and fix that the more “reliable” kind of bug.
Legit happens without a race condition if you’ve improperly linked libraries that need to be built in a specific order. I’ve seen more than one solution that needed to be run multiple times, or built project by project, in order to work.
Isn’t that the definition of a race condition, though? In this case, the builds are racing and your success is tied to the builds happening to happen at the right times.
Or do you mean “builds 1 and 2 kick off at the same time, but build 1 fails unless build 2 is done. If you run it twice, build 2 does “no change” and you’re fine”?
I’ve only recently joined the dev world and I saw this post in the morning. Late this afternoon I’m doing a deployment that fails, couldn’t determine the cause as I’m a noob, before bothering a more senior dev for help I run it again… It worked.
For unit tests, you should know the input and expected output from the start. Really responsible devs write the unit tests first, because you should know what you’re going to put in and what you’ll get out before you start writing anything. If you find yourself making the same mistakes in your tests as you do your code, you might be trying to do too much logic in the test itself. Consider moving that logic to its own testable class, or doing a one-time generation of a static set of input/output values to test instead of making them on the fly.
How granular your tests should be is a matter of constant debate, but generally I believe that different file/class = different test. If I have utility method B that’s called in method A, I generally test A in a way that ensures the function of B is done correctly instead of writing two different tests. If A relies on a method from another class, that gets mocked out and tested separately. If B’s code is suitably complex to warrant an individual test, I’d consider moving to to its own class.
If you have a super simple method (e.g. an API endpoint method that only fetches data from another class), or something that talks with an external resource (filesystem, database, API, etc.) it’s probably not worth writing a unit test for. Just make sure it’s covered in an integration test.
Perhaps most importantly, if you’re having a lot of trouble testing your code, think about if it’s the tests or the code that is the problem. Are your classes too tightly coupled? Are your external access methods trying to perform complex logic with fetched data? Are you doing too much work in a single function? Look into some antipatterns for the language/framework you’re using and make sure you’re not falling into any pitfalls. Don’t make your tests contort to fit your code, make your code easy to test.
If ever you feel lost, remember the words of the great Testivus.
Really responsible devs write the unit tests first, because you should know what you’re going to put in and what you’ll get out before you start writing anything.
I’ve obviously heard the general concept, but this is actually pretty helpful, now that I’m thinking about it a bit more.
I’ve written pretty mathy stuff for the most part, and a function might return an appropriately sized vector containing what looks like the right numbers to the naked eye, but which is actually wrong in some high-dimensional way. Since I haven’t even thought of whatever way it’s gone wrong, I can’t very well test for it. I suppose what I could do is come up with a few properties the correct result should have, unrelated to the actual use of it, and then test them and hope one fails. It might take a lot of extra time, but maybe it’s worth it.
How do you deal with side effects, if what you’re doing involves them?
For your vector issue, I’d go the route of some static examples if possible. Do you have a way to manually work out the answer that your code is trying to achieve?
For side effects, that may indicate what I referred to as tightly coupled code. Could you give an example of what you mean by “side effect”?
For your vector issue, I’d go the route of some static examples if possible. Do you have a way to manually work out the answer that your code is trying to achieve?
Not necessarily. In this scenario I’d imagine it’s a series of numbers as opposed to something more human-friendly exactly because there’s internal complexity that’s important but hard to manually survey, let alone generate. If you’ve worked with GANs at all, maybe it’s a point in a latent space.
For side effects, that may indicate what I referred to as tightly coupled code. Could you give an example of what you mean by “side effect”?
I mean it in the standard functional language way, if you’re familiar. There’s an operation that happens at some step of an algorithm, and it changes a data structure which is referred to or updated at another step. Sometimes you can’t really avoid it, because the problem itself has an interconnection like that.
A sorting algorithm example, if that doesn't make this too complicated.Concurrency it’s pretty much guaranteed to do it, so let’s say we’re trying to implement some sort of bespoke sorting algorithm, where each compare is large and complex enough we have bugs, and which runs in multiple threads. If threads are interfering with each other in this program, how do you test for that? The whole thing won’t give expected results, obviously, but another unsorted array or a failure to terminate doesn’t tell you much. Each compare and each swap might look correct at first, and give properly typed results. Let’s assume that each thread might traverse to anywhere in the array, so you can’t just check when they’re overlapping.
programmer_humor
Newest
This magazine is from a federated server and may be incomplete. Browse more on the original instance.