Comment by akavel | Hacker News Reader

Comment by akavel | Hacker News Reader

In section titled "3. Write Fewer, Valuable Tests", I don't understand the terminology ("controllers and plugs"), which I assume is some stuff in the Phoenix framework that I have no idea about. Can somebody possibly explain to me what are the "controllers and plugs" here? I'm very interested in learning a more general idea (how to effectively reduce lines of tests) from this nugget, that I could hopefully translate to different languages & frameworks I use...

Quoting the relevant fragment in full:

"We focused our automated tests on our controller actions and plugs rather than going for 100% test coverage. Since these are the main ways that the Phoenix application interfaces with the outside world, they’re the critical points of failure.

Controller tests also exercise a lot of the code paths in your application, making it less necessary to unit test every single module. As a result, you end up with fewer tests, which makes it easier to do refactoring, provided your changes preserve the behavior of the controllers and plugs."

Controllers are the normal "C" inside MVC. That stuff that talks to your Models and passes it to the view / template layer.

Plug [0] on the other hand is something like "rack" in the ruby world, a "A specification for composable modules between web applications". Phoenix is built on plug.

I think very simple you could say that plugs are pipes or similar to middlewares - functions that take the connection, transform it or do some checks based on something, then pass it to the next plug. Like a pipe full of functions.

Because phoenix is built on it, it is very easy to specify custom plugs and add them to your request / transform pipeline.

Someone correct me if I explained that wrong.

[0]: https://github.com/elixir-lang/plug

So, it's slang for plug-in(s)? (services, extensions, ...)

they did black box unit test instead of proper unit test.

e.g. if a method is private, it's not tested.

that's the usual way when full reliability is not worth the dev time, or when devs think functional tests only are enough but still want a tap on the back for having unit tests and coverage numbers.

in their case it's the later as you can see for: "Controller tests also exercise a lot of the code paths in your application"

classical functional tests being called unit tests excuse. not that functional is better or worse, but correct names are better no matter what.

They don't call them unit tests though do they?

The thing about unit testing is that you have to decide what your "unit" is. It could be down to the function/method level, but that's not always appropriate. Such a strict testing framework can leave you immobilized when you want or need to refactor.

Their HTTP API is their interface for the application. It makes a great deal of sense to focus on that level for their testing (note: they didn't say they didn't test internals, they said they focused on the external interfaces).

Reply on news.ycombinator.com