I would suggest writing the use cases for your app and translating them into tests. It’s much better to have the unit of the test be a business use case then a context, module, function or a table.

I don’t know the details of your domain and app, so I’m going to make a bunch of assumptions. I’d suggest something like this:

describe "enrolling into a class" do
  test "a student can enroll to a class" do
    admin = AdminUI.create_admin()
    class = AdminUI.create_class(admin)
    student = AdminUI.create_student(admin)
    
    enrollment = StudentUI.enroll_to_class(student, class)

    assert enrollment.success
  end

  test "a student cannot enroll if the class is full" do
    admin = AdminUI.create_admin()
    class = AdminUI.create_class(admin, capacity: 3)
    for i <- 1..3 do
      student = AdminUI.create_student(admin)
      StudentUI.enroll_to_class(student, class)
    end

    student = AdminUI.create_student(admin)
    enrollment = StudentUI.enroll_to_class(student, class)
    
    assert !enrollment.success
  end
end

AdminUI and StudentUI are test helpers that model the actions that admins and students can perform in your app. It’s up to you to decide what’s the best way to implement those: you can use the API if you have one, use context or insert straight into the DB if that makes sense.

This way, the tests are going to be disconnected from the implementation and you’ll have much greater freedom in changing things if needed.

hmmm, your question is more of code structuring, and there’s room for opinion & preference on it, so i would answer just like how i would prefer to do it:

1. Yes, i generally like to split module which deals with low level data (Enrollment, Classes) with module that govern business logic. in this case you mix actual DB creation logic of enrollment with business logic,
2. yes, you should test the business logic code part, but testing insert_enrollment is a bit dubious (for me anyway) as it’s really standard code from ecto, i usually trust ecto to do it’s job.
3. if you do split the module, having create_enrollment would be better as it’s more standard.

just for example, here’s how business logic code might be:

defmodule Enrol.EnrolService do
  
  def enroll_student(student, class) do
    Repo.transaction(fn ->
      if Classes.class_have_existing_capacity?(class) do
        Enrollment.create_enrollment(attrs)
      else
        Repo.rollback(:class_full)
      end
  end)
end
  

shortly before midnight, but all tests written and passing now thank you all for help!