WIP: Add projects context #1270
Conversation
- Updated "changesets"/"with valid attributes" to use Projects.change_project
|
Note: Do ignore the hard coded attribute in the initial pull :) |
|
|
||
| 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"}) |
There was a problem hiding this comment.
Should this not go into a separate test for the Projects context?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
Interesting. Not sure I'm fully caught up on 1.3 enough to understand the reasoning behind this.
There was a problem hiding this comment.
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 :)
There was a problem hiding this comment.
@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.
begedin
force-pushed
the
develop
branch
18 times, most recently
from
e075407
to
6d6cc63
Compare
What's in this PR?
Up for dicussion
TODO (pending discussion)