radanskoric

7 ms·

1.
by radanskoric 9mo ago
Author here. I didn't mention it because I wasn't writing an evaluation of fixtures. Just writing about how to make better use of fixtures. I actually use both fixtures and factories depending on the project specifics and also whe
2.
by radanskoric 9mo ago
It's required for tests to clean up after themselves. With Rails and fixtures this is handled by default: each test runs inside a transaction which is rolled back at the end of the test. That way each test starts with the same initial
3.
by radanskoric 9mo ago
I'm with you on the one assertion per test. I bundled two assertions into the same test here because my whole point was to have them effectively together describe a single test, just in a more maintainable manner. Regarding the fact th
4.
by radanskoric 9mo ago
Ah, ok, now I understand. Ok, I wasn't talking about that. From what I understand about property based testing it's sort of half way between regular example based testing and formal proofs: It tries to prove a statement but instea
5.
by radanskoric 9mo ago
Ah, Ok, yes, for API endpoints it makes a lot of sense. Especially if it's a public API, you need to inspect the output anyway, to ensure that the public contract is not broken. But, I spend very little or no time on API endpoints sinc
6.
by radanskoric 9mo ago
Author here. Yes, what you describe sound where much like what I call Factories (and that's what they're usually called in Ruby land, and some other languages). The problem arises when they're used to generate Database record
7.
by radanskoric 9mo ago
I think I'm getting what you mean and I almost completely agree with you, let me address one part, the only part where I don't agree: > Plus you do gain testing power, because you can test more things. For example, you can conf
8.
by radanskoric 9mo ago
I'm familiar with snapshot testing for UI and I agree with you, they can work really well for this because they're usually quick to verify. And especially if you can build in some smart tolerance to the comparison logic, it can be
9.
by radanskoric 9mo ago
When you say inheritance do you mean DRY as in "Don't repeat yourself"? I'm not sure what you mean by inheritance in tests but DRY is criminally overused in tests. That could be a whole separate article but the tradeoffs
10.
by radanskoric 9mo ago
In theory you're 100% right, a true unit test is completely isolated from the rest of the system and than a lot of the problems disappear. In reality, that is also not free. It imposes some restrictions on the code. Sometimes being pra
11.
by radanskoric 9mo ago
Your thinking is sound. At the end of the day Rails default fixtures is nothing more than some code that reads yaml files and creates records once at the start of test suite run. So you can definitely use FactoryBot to create them. However,
12.
by radanskoric 9mo ago
Author here. I'm a big fan of factories but the slowness is a real drag on large test suites. If you're considering switching, remember that you can do it gradually, there's no law against using both fixtures and factories in
13.
by radanskoric 9mo ago
Author here. Thanks for writing up your thoughts on this! The "doesn't include non-active projects objections is easy", please check the Example 1 test again, there's a line for that: ``` refute_includes active_proje
14.
by radanskoric 9mo ago
Author here, thanks for posting. :)
15.
by radanskoric 10mo ago
Woah, this thread escalated quickly.
16.
by radanskoric 10mo ago
Can you explain why you say they would be better off? What else would be a better choice and why?
17.
by radanskoric 10mo ago
Have you used it over the last few years? It has it been rapidly improving, mainly because Shopify put a team full time on it. It doesn’t take a lot of people to optimize a VM/interpreter it just has to be the right people. And the que
18.
by radanskoric 1y ago
It's a sharp knife. You can create a messy nightmare or a clean super readable codebase, it's up to how good the author is.
19.
by radanskoric 1y ago
No worries, I didn't think that's the case. :) It's an interesting conversation.
20.
by radanskoric 1y ago
That was my misunderstanding as well. That's why I wrote the article. Btw, it's not even about the RubyLLM gem. The gem abstracts away the calling of various LLM providers and gives a very clean and easy to use interface. But it&#
21.
by radanskoric 1y ago
Interesting. I've not used it but this sounds like the tools that were exposed to it need improvement. Everything you describe seems like it should be mostly in reach of current larger models.
22.
by radanskoric 1y ago
Yes, exactly, Ruby has the human readability expressiveness. If you say that expressivity is the ability to implement a program in less lines of code then Ruby is more expressive than most but less than for example Clojure. Well written Clo
23.
by radanskoric 1y ago
It's good that you commented. I see more than a few people are getting caught up on the number of lines so it's good that I clarify.
24.
by radanskoric 1y ago
Why are people always the reason why we can't have nice things... :D
25.
by radanskoric 1y ago
That's a very neat idea, maybe even add something like browser-use to allow it to implement a Rails app and try it out automatically. I think you should try it. :) I'm being serious. This sounds like a fun project but I have to tu
26.
by radanskoric 1y ago
I didn't put the number into the title to make it a competition. LoC is a poor metric. I put it to communicate to the reader that they won't have to spend a lot of time reading the article to get a full understanding. I always put
27.
by radanskoric 1y ago
It depends on the flexibility of the API. If you're making an API for just one specific use case, you can make it a one liner in any language, even assembler: just push the exact specific functionality into the one function. Language e
28.
by radanskoric 1y ago
I put the lines of code into the title to communicate to the reader that they can get a good understanding just by reading this article. Basically, what I wanted to say was: "Here is an article on building a prototype coding agent in R
29.
by radanskoric 1y ago
That's an excellent point. Code was always read more than written. With AI it shifts even more towards reading so language readability becomes even more important. And Ruby really shines there.
30.
by radanskoric 1y ago
If a certain user is susceptible to having the LLM convince them to run an unsafe command, I fear we can't fix that by trying to trick the LLM. :D Either the user needs to be educated or we need to restrict what the user themselves can

More ›