I have some concerns about writing too much logic in the spec tests.
So let's assume we have a student
with statuses
and steps
Student statuses starts from
pending -> learning -> graduated -> completed
and steps are:
nil -> learning_step1 -> learning_step2 -> learning_step3 -> monitoring_step1 -> monitoring_step2
With each step going forward a lot of things are happening depending where you are: e.g.
nil -> learning_step1
Student status changes to learning
Writes an action history ( which is used by report stats ) Update a contact schedule
learning_step1 -> learning_step2
....the same...
and so ..... until
learning_step3 -> monitoring_step1
Student status changes to graduated
Writes different action histories ( which is used by report stats ) Update a contact schedule
and when
monitoring_step2 -> there is no next step
Student status changes to completed
Writes different action histories ( which is used by report stats ) Delete any contact schedule
So imagine that I need a test case of a completed
student, I would have to think all the possibilities that may come and achieve that student as completed
and also I can forget to write an action history and will mess with the reports.
Or ....
Using an already implemented class:
# assuming we have like in the above example 5 steps I do
StepManager.new(student).proceed # goes status learning and step1
StepManager.new(student).proceed
StepManager.new(student).proceed
StepManager.new(student).proceed # goes status graduated and monitoring1
StepManager.new(student).proceed # this will proceed the student in the 5th step which is monitoring2
StepManager.new(student).next_step # here will go completed
or to make my job easier with something like:
StepManager.new(student).proceed.proceed.proceed.proceed.proceed.proceed
or
StepManager.new(student).complete_student # which in background does the same thing
And by doing that I am sure I will never miss something. But then the tests wouldn't be so clear about what I am doing.
So should I replicate the logic or using my classes?