You aren't wrong for some apps, but when an app is designed well I tend to find this is less relevant.
Eg if you put your code behind a single isolated layer you can easily mock out that layer for testing. Take the following interface:
typeUserDBinterface{ByID(iduint)(*User,error)Create(user*User)error// and more}
And all of your SQL code is hidden in an implementation of that interface, you can create a mock implementation for all of your tests and it doesn't matter if you used SQL or an ORM in development - your mock replaces either.
Where this tends to fall apart is when developers scatter ORM (or SQL) code all around in their application, as is more common in rails, and then you end up with something that is harder to test because literally any piece of code could be calling a method on the ORM directly.
In rails this isn't as bad because it isnt' a typed language, you can monkey patch, and you can inject stubs/mocks in your tests at runtime. In Go this doesn't work, so having a better design upfront is necessary.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
You aren't wrong for some apps, but when an app is designed well I tend to find this is less relevant.
Eg if you put your code behind a single isolated layer you can easily mock out that layer for testing. Take the following interface:
And all of your SQL code is hidden in an implementation of that interface, you can create a mock implementation for all of your tests and it doesn't matter if you used SQL or an ORM in development - your mock replaces either.
Where this tends to fall apart is when developers scatter ORM (or SQL) code all around in their application, as is more common in rails, and then you end up with something that is harder to test because literally any piece of code could be calling a method on the ORM directly.
In rails this isn't as bad because it isnt' a typed language, you can monkey patch, and you can inject stubs/mocks in your tests at runtime. In Go this doesn't work, so having a better design upfront is necessary.