Speed Up Your Rails Specs
blog.originate.com
Speed Up Your Rails Specs
1–10 of 13 posts
Re: Speed Up Your Rails Specs
#2RE: Developing Decoupled Code
Extra complexity cost is insane and probably not worth it. Basically you move all your crazy stubbing and mocking out of test code and into application code. Do not do this unless you really, really need this kind of dependency injection.
Re: Speed Up Your Rails Specs
#3"expect(widget_factory).to have_received(:create).with({name: 'sprocket'})"
Even better:
expect("my_service.rb", "line X").to be("widget_factory.create")
Or yet better, simply:
; # realize that testing the exact implementation is bullshit
Re: Speed Up Your Rails Specs
#4Maybe if ruby didn't take so long to load rails code, this sort of complexity wouldn't be necessary...
Re: Speed Up Your Rails Specs
#5speed up by 10? Move to python.
Speed up by 100? Move to Go.
Speed up by 1000? Move to C++.
Re: Speed Up Your Rails Specs
#6RE: Developing Decoupled Code Extra complexity cost is insane and probably not worth it. Basically you move all your crazy stubbing and mocking out of test code and into application code. Do not do this unless you really, really need this kind of dependency injection.
Back in the day, we laughed at people who stuffed all their code into button click handlers.
Now, we mock people who don't.
My, how different the web is!
Re: Speed Up Your Rails Specs
#7The problem with dependency injection in this manner is that your test code is using a fake class that's injected while your production code is using a real class.
This is fine if all you want to do is unit test your classes. That's beside the point though -- I would posit if you're bolting dependency injection onto your interfaces just to make your tests faster, you're not doing it right. Instead, bring that dependency injection into the forefront: to the constructor. Yes, this means to make an object, you'll have to make another object first, both in your production and test code. But now your interface acts the same way in both places. If this sounds very Java-like, well... maybe Java got it right. (There was an article on the Twitter blog in the early days about this but I can't remember where it is now...)
Of course, this is going to introduce complexity and now you have to decide whether that complexity is worth it.
Re: Speed Up Your Rails Specs
#8I like that the "tightly coupled" service class is 3 extremely simple LOC that should probably just be in a controller anyway, which is "fixed" by creating a class with 3X as many methods and at least twice as much logic to follow, plus a spec twice as long as the original class that tests nothing other than the fact that when you call a method with a set of arguments, that method receives that set of arguments.
Re: Speed Up Your Rails Specs
#9RE: Developing Decoupled Code Extra complexity cost is insane and probably not worth it. Basically you move all your crazy stubbing and mocking out of test code and into application code. Do not do this unless you really, really need this kind of dependency injection.
Back in the day, we laughed at people who stuffed all their code into button click handlers. Now, we mock people who don't . My, how different the web is!
That's a straw man. I see how you made it up for a joke, but it's still confusing. "Don't overengineer" is not the same as "stuff all your code into button click handlers".
Re: Speed Up Your Rails Specs
#10speed up by 10? Move to python. Speed up by 100? Move to Go. Speed up by 1000? Move to C++.
Note: Ruby and Python have pretty nearly identical performance for most workloads these days. Other than that, it's an illustrative point - if what you really care about is execution speed, you should pick a language that focuses on it more. It's interesting that increased developer productivity is the classic trade-off for decreased execution speed, but that all these "my tests are slow" issues are basically decreased execution speed impacting developer productivity.