138 karma · joined November 13, 2013
- https://paulhammant.com/2012/04/24/call-to-arms-average-stor...
Just like me! I also suffer from the same disease, but on a much more serious level… lol! Everything just crashed yesterday and the count was on 270+… :-o
If you're speaking HTML it can be as simple as:
<form action="/close-account?acc_number=12345" method="POST">
<button>Close Account</button>
</form>
Or even: <form action="/close-account" method="POST">
<input type="hidden" name="acc_number" value="12345">
<button>Close Account</button>
</form>
If you're speaking Siren (https://github.com/kevinswiber/siren): {
"actions": [
{
"title": "Close Account",
"method": "POST",
"href": "/close-account",
"type": "application/x-www-form-urlencoded",
"fields": [
{ "name": "acc_number", "type": "hidden", "value": "12345" }
]
}
]
}Decoupling from your persistence (and presentation, fwiw) brings a lot of benefits, not only faster tests. I'm sick of people saying "why introduce a layer here if we'll never change the database?". The answer is simple: yes, you will change the database, specially when testing where you want to plug an in-memory store.
Again, I get that Rails gives us conventions so we don't keep bikeshedding, but how often do we challenge these conventions? How often do we question whether the problem we're solving fits the CRUD/MVC patterns?
While speeding up the process is always good, tools like lucifer or spork are only masking the problem: loading the whole environment for unit-level tests. Sails, like Rails, promote tight coupling between all parts of the system, which harms test speed, thus harming another development tool: TDD.
The more decoupled and isolated you write your business logic, the easier and faster it is to test drive it. Then you simply plug an HTTP interface (with routes and whatnot) that calls into your core.
I totally agree with you… And what I've been trying to do to whoever I talk to, in my team and outside, is to educate them in this area (sending resources like I did on an earlier post), and try to make them not call any json-based API REST (which in fact has nothing to do with json specifically).