Paul Smith paulcsmith

## part_1
So the proposed solution is to change production code to be "testable" and making production code to call Application configuration for every function call? This doesn't seem like a good option as it's including a unnecessary overhead to make something "testable".

It is improving the design of your code.

A test is a user of your API like any other code you write. One of the ideas behind TDD is that tests are code and no different from code. If you are saying "I don't want to make my code testable", you are saying "I don't want to decouple some modules" or "I don't want to think about the contract behind these components".

Just to clarify, there is nothing wrong with "not wanting to decouple some modules". You don't want to decouple every time you call the URI module, for example. But if we are talking about something as complex as an external API, a SSH connection or such, defining a explicit contract and passing the contract as argument is going to make your code wonders and make it easier to manage your

## fixtures.ex
defmodule MyApp.Fixtures do
  alias MyApp.Repo
  alias MyApp.User

  def fixture(:user) do
    %User{name: "Daniel Berkompas", email: "test@example.com"}
  end

  # Example: create(:user)
  def create(record) do

## brunch-config.js
exports.config = {
  // See http://brunch.io/#documentation for docs.
  files: {
    javascripts: {
      joinTo: 'js/app.js',
      // To use a separate vendor.js bundle, specify two files path
      // https://github.com/brunch/brunch/blob/stable/docs/config.md#files
      // joinTo: {
      //  'js/app.js': /^(web\/static\/js)/,
      //  'js/vendor.js': /^(web\/static\/vendor)/

## view.ex
def render(conn, assigns \\ []), do: render(conn, action_name(conn), assigns)

## gist:959d58b9b4cec1fd5b85
"<?xml version=\"1.0\" encoding=\"utf-8\"?><cfdi:Comprobante xsi:schemaLocation=\"http://www.sat.gob.mx/cfd/3 http://www.sat.gob.mx/sitio_internet/cfd/3/cfdv32.xsd\" version=\"3.2\" folio=\"22\" LugarExpedicion=\"NOGAL 10 , SAN JOSE DE LOS CEDROS, 05200, DELEGACION CUAJIMALPA, DISTRITO FEDERAL, MEXICO\" NumCtaPago=\"NO IDENTIFICADO\" TipoCambio=\"1.00\" Moneda=\"Peso Mexicano\" fecha=\"2014-01-29T20:41:07\" sello=\"gO/DyxBs7kneK2dRySKmKshc1ddFXj+XcoPUrlgHYNyGeeuXGHW81URpiy20wIMpUmtZf8yne+5+jHMTqachVghB4IRkJwUNiFNPmc5K/vxiY/VWzalzQtrkBKZh7LWs/yrinvoiP1H4h8t/yOsiw+8NRwSDfcV6g70b3jnZRKg=\" formaDePago=\"PAGO EN UNA SOLA EXHIBICION\" noCertificado=\"00001000000301474075\" certificado=\"MIIEdzCCA1+gAwIBAgIUMDAwMDEwMDAwMDAzMDE0NzQwNzUwDQYJKoZIhvcNAQEFBQAwggGKMTgwNgYDVQQDDC9BLkMuIGRlbCBTZXJ2aWNpbyBkZSBBZG1pbmlzdHJhY2nDs24gVHJpYnV0YXJpYTEvMC0GA1UECgwmU2VydmljaW8gZGUgQWRtaW5pc3RyYWNpw7NuIFRyaWJ1dGFyaWExODA2BgNVBAsML0FkbWluaXN0cmFjacOzbiBkZSBTZWd1cmlkYWQgZGUgbGEgSW5mb3JtYWNpw7NuMR8wHQYJKoZIhvcNAQkBFhBhY29kc0BzYXQuZ29iL

## gist:2615513d0602915fb98b
def with_sorted_comments do
  from a in Announcement,
    left_join: c in assoc(a, :comments),
    left_join: u in assoc(c, :user),
    order_by: [asc: c.inserted_at],
    preload: [:interests, :user, comments: {c, user: u}]
end

## comment_view.ex
defmodule MyApp.CommentView do
  use MyApp.Web, :view
  @attributes ~W(id name inserted_at)

  def render("index.json", %{data: comments}) do
    for comment <- comments, do: render("show.json", %{data: comment})
  end

  def render("show.json", %{data: comment}) do
    comment

## gist:dcb8adb3749cfec00960
text-rendering: optimizeLegibility;
-webkit-font-smoothing: antialiased;

## test_helper.exs
# Works great in test/test_helper.exs
:erlang.system_flag :backtrace_depth, 50

## gist:08f9763fb88290e3f7ea
@moduledoc File.read!("README.md")
	So the proposed solution is to change production code to be "testable" and making production code to call Application configuration for every function call? This doesn't seem like a good option as it's including a unnecessary overhead to make something "testable".

	It is improving the design of your code.

	A test is a user of your API like any other code you write. One of the ideas behind TDD is that tests are code and no different from code. If you are saying "I don't want to make my code testable", you are saying "I don't want to decouple some modules" or "I don't want to think about the contract behind these components".

	Just to clarify, there is nothing wrong with "not wanting to decouple some modules". You don't want to decouple every time you call the URI module, for example. But if we are talking about something as complex as an external API, a SSH connection or such, defining a explicit contract and passing the contract as argument is going to make your code wonders and make it easier to manage your
	defmodule MyApp.Fixtures do
	alias MyApp.Repo
	alias MyApp.User

	def fixture(:user) do
	%User{name: "Daniel Berkompas", email: "test@example.com"}
	end

	# Example: create(:user)
	def create(record) do
	exports.config = {
	// See http://brunch.io/#documentation for docs.
	files: {
	javascripts: {
	joinTo: 'js/app.js',
	// To use a separate vendor.js bundle, specify two files path
	// https://github.com/brunch/brunch/blob/stable/docs/config.md#files
	// joinTo: {
	// 'js/app.js': /^(web\/static\/js)/,
	// 'js/vendor.js': /^(web\/static\/vendor)/
	def with_sorted_comments do
	from a in Announcement,
	left_join: c in assoc(a, :comments),
	left_join: u in assoc(c, :user),
	order_by: [asc: c.inserted_at],
	preload: [:interests, :user, comments: {c, user: u}]
	end
	defmodule MyApp.CommentView do
	use MyApp.Web, :view
	@attributes ~W(id name inserted_at)

	def render("index.json", %{data: comments}) do
	for comment <- comments, do: render("show.json", %{data: comment})
	end

	def render("show.json", %{data: comment}) do
	comment
	text-rendering: optimizeLegibility;
	-webkit-font-smoothing: antialiased;
	# Works great in test/test_helper.exs
	:erlang.system_flag :backtrace_depth, 50