paulcsmith

def render(conn, assigns \\ []), do: render(conn, action_name(conn), assigns)

paulcsmith

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)/

paulcsmith

defmodule MyApp.Fixtures do
  alias MyApp.Repo
  alias MyApp.User

  def fixture(:user) do
    %User{name: "Daniel Berkompas", email: "[email protected]"}
  end

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

paulcsmith

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 

paulcsmith

• factory(factory_name) to define a factory

factory(:user) do
  %User{name: "John"}
end

• create(:user, name: "Jane")
• build(:user, name: "Jane")
• assoc(:author, factory: :user) (can only be used inside factory definition)

paulcsmith

# This is a bit more flexible. Worried people will try to call it directly :S
# Also throws warnings if you put functions in between the function definitions
def factory(:user, attrs) do
  %User{
    first_name: "Paul"  ,
    last_name: "Smith"
    email: put_new_email(attrs)
  }
end

paulcsmith

defmodule MyApp.Factory do
  use ExMachina.Ecto, repo: MyApp.Repo

  def factory(:interest, attrs) do
    %Interest{
      name: sequence(:interest_name, &"interest-#{&1}")
    }
  end

  def factory(:user, attrs) do

paulcsmith

defmodule MyApp.AnnouncementTraits do
  def with_subscriber(announcement, user) do
    create(:subscription, announcement: announcement, user: user)
    announcement
  end
  
    def tag_with_interest(announcement, interest) do
    create(:announcement_interest, announcement: announcement, interest: interest)
    announcement
  end

paulcsmith

Bypass fake_stripe do
  get "soemthing" do
    send_resp conn, ""
  end
end

paulcsmith

Books & in depth resources

• Phoenix Guides - This is one the best ways to get started. The guides cover most of the fundamental topics and explain the ins and outs of how Phoenix works. I would start here and look up the parts of Elixir you don't understand as you go.
• Programming Phoenix - Still in beta, but very well done. I would recommend getting it even while in beta. It has a brief introduction to Elixir and covers all the important concepts in Phoenix
• Elixir Getting Started Guide - This is the official Elixir getting started guide. You don't need to know everything here to get started, but it covers a lot of fundamentals in sections 1-21.

Specific Phoenix Guides that are very helpful

• routing - Covers the router and pipelines
• [plug](http://www.phoenixframework.org/do