Skip to content

Refactor core code in common to be a set of POROs with thor wrappers #50

Description

@eightBitter

The way you have this now, you are going to have to call get_subjects to test make_index, so in order for tests to pass, you need stable data to test against via live API call (slow, flaky) or to use something like VCR to mock what that result would be. Same for attach_subjects, which invokes make_index
This kind of setup leads to hard to write/setup tests that are hard to maintain when something changes. (I have some similar problems in collectionspace-mapper which has this same overall problem without involving Thor)
You can greatly simplify the testing by sorta complicating the code. I'm not 100% sure what's going on with your *args here, and undoubtedly this will not straight up work if dropped in, but here's an sketchy idea of what I mean:
https://gist.github.com/kspurgin/94c20bfe513304951d6fcc30abc85ff1
It takes the idea of putting your code's actual behavior into Plain Old Ruby Objects (POROs) and mixes in some semi/pseudo dependency injection so the POROs can be called in isolation from one another. I.e. in production, they call on each other like the invoke s you have now, but in testing you can pass in basic test data easily.
Then the Thor commands are just dumb wrappers around already tested external code, or your own tested code.

Metadata

Metadata

Assignees

Labels

enhancementNew feature or request

Type

No type

Fields

No fields configured for issues without a type.

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions