[stouset]

Do you mind elaborating on what more you end up wishing you had?

Most of the additional features RSpec adds seem worthwhile but just end up being more complicated/confusing in the end, in my experience. Shared contexts/examples, for example. Others like let blocks should… just be methods.

I will say the change in… I think it was RSpec 3(?) to the expect(x) syntax was a hugely positive change, particularly in not having to monkeypatch the world.

[davetron5000]

The biggest thing is the mocking system. MiniTest's feels so difficult to use.

I also like creating custom matchers vs. creating my own assert_* methods.

I would agree that many features of RSpec are, honestly, bad: shared examples, shared contexts, etc. Excessive use of let! and let, plus the predicate matchers are all just really confusing to me.

I actually thought about patching the RSpec gem to remove the features I didn't like :) Might still consider it heh

[stouset]

The mocking thing actually touches on another point of frustration for me. I think the design of Rails ends up causing people to reach for mocking way too often in order to test things. At a glance I think Brut should avoid a lot of this by having things just be plain old Ruby objects.

I have dealt with countless Rails projects where testing things conventionally was difficult or impossible so mocks/stubs had to be used everywhere (controllers are the worst offenders here). When you start digging in to what's actually being tested, you find that the tests express little more than "this method is written the way it's currently written" rather than actually testing behavior.

Good tests should do three important things: catch bugs early in development, prevent regressions, and allow refactoring. Overly-mocked tests not only end up doing none of these but often actively work against these goals. They can't catch bugs because they reaffirm the current implementation rather than testing behavior. They can't catch regressions because any change to the code necessitates a change to the test. And they actively inhibit refactoring for both of those reasons.

All that is to say that maybe having a less-convenient mocking system is maybe a good thing :)

Also, since you're here, I want to say it also looks like your design encourages avoiding one of my other huge issues with Rails. I hate that ActiveRecord conflates the ORM layer with domain logic. This causes an antipattern where consumers of records (usually controller methods) pierce all the way down into the database layer by using AR methods and attributes directly. While convenient, this makes doing database-layer changes excruciating since your table layout is implicitly depended upon by pieces everywhere throughout the stack.

Better is to do what it looks like you suggest here: there should be an ORM layer that just exposes the database structure, and then you should layer domain objects on top of that which expose higher-level methods for interacting with persisted objects. If you change the database, you only need to change the mid-level layer. None of its consumers need to care that the underlying table layout changed.

From what I can tell so far I am very excited about Brut.

[davetron5000]

Yeah, that makes sense. Where I end up wanting mocks is when this happens:

1 - build first version of feature, all core logic in a class I can test conventionally 2 - logic gets complex, test gets complex 3 - Eventually, I need to create some layering, where the class from step 1 now delegates to other classes. The initial test is more like an integration test and gets harder to keep up

At this point, there is a camp that says I should be using dependency injection and inject null objects for the dependencies. I get that idea. I am in the other camp that does not want to make custom objects just to satisfy a test. A mocking system can do that for me. So that's what I would do - mock the dependencies. The "real" versions would be tested conventionally.

I definitely do NOT just start with mocking imaginary internals though - I guess that's a whole other camp :)

[hotpocket777]

_in your opinion_

My opinion is, _my unit tests_ are to protect my code against unwanted changes. To that end, unit tests test a single unit. And everything is mocked. If I have to rewrite a method, usually I rewrite all of its unit tests. Which is fine. They’re easy to write or rewrite.

Fully mocked unit tests are then supplemented with fewer “full stack” tests higher up the pyramid.

[stouset]

> My opinion is, _my unit tests_ are to protect my code against unwanted changes.

This is just about the most bizarre take on unit testing I've seen in my 25-year career.

> If I have to rewrite a method, usually I rewrite all of its unit tests.

If you have to rewrite your tests every time you rewrite a method, you are entirely defeating the point of testing. What value you get from tests that only assert that the current implementation is equal to the current implementation?

[1123581321]

You seem confused about what he was saying. I’m sure you are familiar with unit testing philosophy with your experience. Calling a function and expecting a response does test the behavior of the application, just at a lower level than a request- or multi-request level spec. When he says rewriting a method he is referring to changing the logic of it; a refactor leaves the tests unchanged. That shouldn’t have needed to be spelled out to such a senior developer.

[stouset]

Tests should not generally need to be rewritten unless you’re changing the externally-visible behavior API of a function or library (either the literal API, its effects, or its semantics).

If you’re changing the tests because you’ve changed the internal, non-externally-visible logic of your code, your tests are almost certainly providing you negative value.

Being able to refactor and re-run your existing test suite to ensure consistent behavior is possibly the important property of a good test suite.

[hotpocket777]

> This is just about the most bizarre take on unit testing I've seen in my 25-year career.

Lol ok

> you are entirely defeating the point of testing

We will disagree here

> only assert that the current implementation is equal to the current implementation

I didn’t state that I do this

[ansisjxbbx]

This is domain specific, but for most web apps

> Fully mocked unit tests are then supplemented with fewer “full stack” tests higher up the pyramid.

Has the wrong priority. Full stack tests are the most valuable for shipping working software. Tests are enforcing contracts between components. Often I’ll see unit tests written for cases that do not exist. This is very bad. Testing at the boundary of your stack ensures the contracts that matter are enforced. Everything else is just making devs wonder “is this requirement actually real?”.

I used to be big on unit tests until I had to maintain a codebase for more than a couple years. I still use them, but mostly out of laziness.

[lloeki]

> I actually thought about patching the RSpec gem to remove the features I didn't like

Hmm it all sounds like you'd end up bastardising Rspec into being Minitest::Spec?

If you really like things like `expect().to` it's much easier to add it to Minitest::Spec (I did it back then, since there's `_().should` it's like 5-10 lines) than removing all those features and suffering the rspec weight.

[dbalatero]

Reading test failure output is much more readable and usable under RSpec vs. Minitest, to my eye.

[Lio]

I agree with this. RSpec may be an extra dependency vs MiniTest but with MiniTest I'll almost always need extra plugins anyway for things like reporting, colour coding, etc.

MiniTest is almost good enough but not quite there on its own.