Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

WIP: Add projects context #1270

Open
wants to merge 1 commit into
base: develop
Choose a base branch
from
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
104 changes: 104 additions & 0 deletions lib/code_corps/projects/projects.ex
Original file line number Diff line number Diff line change
@@ -0,0 +1,104 @@
defmodule CodeCorps.Projects do
@moduledoc """
The Projects context.
"""

import Ecto.Query, warn: false
alias CodeCorps.Repo

alias CodeCorps.Project

@doc """
Returns the list of projects.

## Examples

iex> list_projects()
[%Project{}, ...]

"""
def list_projects do
Repo.all(Project)
end

@doc """
Gets a single project.

Raises `Ecto.NoResultsError` if the Project does not exist.

## Examples

iex> get_project!(123)
%Project{}

iex> get_project!(456)
** (Ecto.NoResultsError)

"""
def get_project!(id), do: Repo.get!(Project, id)

@doc """
Creates a project.

## Examples

iex> create_project(%{field: value})
{:ok, %Project{}}

iex> create_project(%{field: bad_value})
{:error, %Ecto.Changeset{}}

"""
def create_project(attrs \\ %{}) do
%Project{}
|> Project.changeset(attrs)
|> Repo.insert()
end

@doc """
Updates a project.

## Examples

iex> update_project(project, %{field: new_value})
{:ok, %Project{}}

iex> update_project(project, %{field: bad_value})
{:error, %Ecto.Changeset{}}

"""
def update_project(%Project{} = project, attrs) do
project
|> Project.changeset(attrs)
|> Repo.update()
end

@doc """
Deletes a Project.

## Examples

iex> delete_project(project)
{:ok, %Project{}}

iex> delete_project(project)
{:error, %Ecto.Changeset{}}

"""
def delete_project(%Project{} = project) do
Repo.delete(project)
end

@doc """
Returns an `%Ecto.Changeset{}` for tracking project changes.

## Examples

iex> change_project(project)
%Ecto.Changeset{source: %Project{}}

"""
def change_project(%Project{} = project) do
Project.changeset(project, %{})
end
end
4 changes: 2 additions & 2 deletions test/lib/code_corps/model/project_test.exs
Original file line number Diff line number Diff line change
Expand Up @@ -3,14 +3,14 @@ defmodule CodeCorps.ProjectTest do

import CodeCorps.Project

alias CodeCorps.{Project, ProjectUser, Repo}
alias CodeCorps.{Projects, Project, ProjectUser, Repo}

describe "changeset" do
@valid_attrs %{title: "A title"}
@invalid_attrs %{}

test "with valid attributes" do
changeset = Project.changeset(%Project{}, @valid_attrs)
changeset = Projects.change_project(%Project{title: "A title"})
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should this not go into a separate test for the Projects context?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

IMHO no, but it's debatable... by changing the tests to use the context module we will hit all the same places we're already directly testing. And if you gen a phoenix 1.3 project and a few schema under the same context, you'll find that phoenix will put them all in the same test name space (i.e., hammer and chisel tests both go in the the toolbox context test file) . This makes sense to me, but is quite debatable I think.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Interesting. Not sure I'm fully caught up on 1.3 enough to understand the reasoning behind this.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

https://hexdocs.pm/phoenix/contexts.html#content

As far as testing goes.... I would ask, what value do we get out of writing a project context test suite and a project schema test suite? If there is a value, then I'm all about it :)

Copy link
Author

@ghost ghost Dec 17, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@joshsmith thinking on this a few days... I do see the value in having a repo test and context test. At first this seemed like repeating myself... but let's say we only write tests for the context, and not for the repo... then we yank out the context... at that point we would have no tests for our schema module, unless other contexts use it, but this feels brittle. To add to that, we're testing two different things. Our context modules will surely end up having some business logic in them and/or delegate to modules/apps that have that logic, and so just a whole different set of variables and execution paths... Not to mention our context modules may or may not accept or return ecto changesets. TLDR; Different behaviors, inputs, and outputs. Thus it only makes sense to have test units for both. I will rework this.

assert changeset.valid?
end

Expand Down