Open aviflombaum opened 9 years ago
Agree with desire to speed up test running. Good suggestions! @loganhasson should comment on feasibility.
Ya, given how isolated this gem is and that is has coverage - I'd love to see if an 'off-semester' instructor could fix these issues.
cc @jmburges
Steps would be:
If someone picks this up, it'd be nice to add CI Badges on Coverage, Quality, and Dependencies to README, in addition to CONTRIBUTING guidelines / wiki.
Not sure if to raise this here or https://github.com/flatiron-labs/learn-co/ but when running
learn
to run the test suite of a lesson, the first thing it does is authenticate, which is slow, is prone to environmental failure, and delays feedback of test results.When
learn
is evoked and determined to run a lesson's test suite, the priority should be providing the student with meaningful output about the test suite/run. Ideally runninglearn
should be as quick as runningrspec
to the user. Currently, runninglearn
adds a significant delay in the feedback cylce mostly do to authenticating and submitting the test results to Learn.Suggestions
learn
should immediately try to run the test suite for the user and provide output. Upon a run of the test suite, assuming we can rescue complete build/interpreter/compilation failures. we should only then connect to learn and submit the results. But by then, the learner has seen the test suite's output and has even, ideally, be dropped back into an active prompt while the submission of the test runs occur entirely behind the scenes.Through caching or assuming the best from the user (they aren't trying to run it for someone else's credit), do we really need to authenticate every time? We can just assume they are correctly logged in, submit the post with a cached token, then run the test suite. If the POST fails, we can ask them to re-login or trouble shoot.