ruralocity
commented
9 years ago I see in the controller specs that you test that the values in the assigned variable are the correct ones. How do you proceed when the find method is more complex? For example User.search(various_params), you surely have it well tested in the model specs, so what do you check in the controller? That the search method is called and is passed the params? This in my opinion breaks the behaviour testing as it checks that a specific method is called with that exact params (-> fragile tests). But if you call the method and check the results you actually test it 2 times (in the controller and in the model)
In a real project, I would typically not test this as heavily in the controller if the functionality had been moved to another object. However I like writing these tests for the sake of demonstrating how controller tests work, and practicing writing tests in general. They're also useful if my code is doing something unexpected and I want to test user input without spinning up a full feature test—could be that something is causing different values to be passed to User.search, for example.
You duplicated (using shared specs) the same specs for different roles (guest, user, admin), in theory it is a good thing to do (because you want to make sure that it works as expected for everyone), in your experience how much does it affect the time to run all specs? If many actions are shared I guess the times is 2 or 3 times what it'd have been without them
How much time do your tests take to run all specs (models, controllers, features)? And what do you consider "acceptable" and what too much?
It's going to depend. I'm not the right person to ask about an "acceptable" length of time for tests to run, because I'm more interested in making sure I have reliable test coverage for the important parts of my application. I have test suites that run in under a second. I work on one that take 20+ minutes.
As I mention in the book, yes, you can speed this up considerably by relying on unit tests and mocking out implementation details—but that can get you in trouble if your mock behaves differently than the object or service it's pretending to be. If you're an experience developer, then go for it. If you're a newcomer, focus on writing good tests first, then fast tests later.
I see you suggest shoulda, isn't a big duplication mirroring the real code? I mean, you have a spec that says that it { should validate_presence_of(:arms) }, and then in the model you have validates :arms, presence: true... I'm not 100% convinced about that test
If you're writing the tests after you've written the code, then it's probably not necessary. Shoulda and tests like these in general are useful to me when I am practicing TDD and thinking about how an object I'm creating needs to behave.
I see below that Eric asked about background jobs, and you suggested to test them like you suggest testing rake tasks. What about testing that a job is actually scheduled during another action (in a model or controller)? Would you do something like expect(SomeJob).to receive(:perform_later) or is there a better approach?
Yeah, that seems like a reasonable approach to me.
Hi Aaron, I've just finished to read your book and it was very useful to clarify some doubts I had on rails testing.
I have few remaining questions for you:
Thank you!