Migrating from Deprecated Workspace Types
In October 2019, several workspace types were deprecated, and you will no longer be able to publish exercises, projects, or Code Challenges using these workspace types:
- Codex Ruby
- Codex Python
- Static
- Default
TL;DR Migration
Old Workspace | New Workspace | New Test Type |
---|---|---|
Codex Ruby | Ruby | RSpec Test or Component Test |
Codex Python | Python (2) | Python Test or Component Test |
Static | Static-Web or Language-specific | Depedent on workspace type |
Default | Static-Web or Language-specific | Depedent on workspace type |
If choosing a language-specific workspace type, refer to Workspace:File Extension Mappings to run the correct file extension.
Codex Ruby
Context
Codex-Ruby is the workspace type in one of Codecademy's oldest extant courses, Learn Ruby. It should not be used for new Ruby content, and the Ruby
workspace type provides all necessary functionality to execute Ruby code with the following caveat: interactive input using the gets
function will not run or be tested properly in Ruby workspaces using the Run button. Either change to using an interactive terminal and having learners execute their code from the terminal, or ask the LX team to force publish your changes.
Migrating Codex-Ruby
After changing the workspace to Ruby, you must also update tests to run Rspec Test
instead of Codex SCT
. You can rewrite from scratch using the RSpec documentation, or you can try to migrate:
Workspace updates
Add a spec
folder at the root level of the workspace.
Add a Gemfile
at the root level with the following contents: gem 'rspec', '3.1'
.
How CodexSCT Ruby tests work
CodexSCT tests first execute learner code and then run test code with global variables from the learner's code in the test context. If an error occurred during execution of the learner's code, a global exception
object is also present in the test context.
Test pass/fail state is determined by a return
statement. true
returns will pass the test, where any string is interpreted as an error message to surface to learners:
# Check for any execution errors:
if exception:
return "Looks like you had the following error: " + exception.to_str
end
# Test a learner variable's existence:
try:
variable_name
rescue NameError:
return "Looks like you did not define `variable_name`."
end
if variable_name != 3:
return "Make sure that `variable_name` equals 3"
end
# Pass the test if all else checks out:
return true
Translating to RSpec Tests
RSpec test differences from CodexSCT:
- RSpec tests require the rspec
describe
/it
block structure. - No learner globals are automatically inserted into an RSpec test's scope. Instead,
binding
andeval()
must be used to load local variables from learner code (see below). - Instead of
return
s, rspecexpect()
assertions are used to test code. If the test file runs with no exceptions raised from anexpect()
, the code passes.
To replicate the above CodexSCT
test with Rspec Test
:
describe 'filepath' do
it 'test case...' do
$b = binding
begin
eval(File.read('<filepath>'), $b)
rescue SyntaxError
expect(1).to eq(0), "It looks like there's a syntax error in your code."
end
begin
$b.eval('variable_name')
rescue NameError
# Manually raise an exception
expect(1).to eq(0) "Looks like you did not define `variable_name`"
end
value = $b.eval('variable_name')
expect(value).to eq(3) "Make sure that `variable_name` equals 3"
end
end
Codex Python
Context
Codex-Python is the workspace type in one of Codecademy's oldest extant courses, Learn Python, and it executes Python 2 code. It should not be used for new Python content, and the Python
workspace type provides all necessary functionality to execute Python code with the following caveat: interactive input using the raw_input()
function will not run or be tested properly in Python workspaces using the Run button. Either change to using an interactive terminal and having learners execute their code from the terminal, or ask the LX team to force publish your changes.
Migrating Codex-Python
After changing the workspace to Python (not Python 3), you must also update tests to run Python Test
instead of Codex SCT
. You can rewrite from scratch using the Python Testing API, or you can try to migrate:
How CodexSCT Python tests work
CodexSCT tests first execute learner code and then run test code with global variables from the learner's code in the test context. If an error occurred during execution of the learner's code, a global error
object is also present in the test context.
Test pass/fail state is determined by a return
statement. True
returns will pass the test, where any string is interpreted as an error message to surface to learners:
# Check for any execution errors:
if error:
return "Looks like you had the following error: " + str(error)
# Test a learner variable's existence:
try:
variable_name
except NameError:
return "Looks like you did not define `variable_name`."
if variable_name != 3:
return "Make sure that `variable_name` equals 3"
# Pass the test if all else checks out:
return True
Translating to Python Test
Python test differences from CodexSCT:
- Instead of
return
s, call thefail_tests(<message>)
orpass_tests()
function to determine test result - Code globals must be explicitly imported into context with
load_file_in_context()
. This will automatically fail tests if any Exceptions are raised during execution. If you do not want to automatically fail these tests and handle the error in the test file, use the following code blocks in atry
/except
:
To replicate the above CodexSCT
test with Python Test
:
Static
Context
Static workspace provides a static webserver to server learner files to the Web Browser component. As a side effect of past code execution architecture, it could also be used as code runner and execute code to a terminal based on the file extension.
Migrating Static
If the workspace requires learner code to be run in the back-end (such as executing a Java or Python file), use those language-specific workspace types. If the workspace is used to serve HTML/CSS/front-end JS files with a web browser cmponent, use the Static-Web workspace type.
Default
Context
Default workspaces allow for basically all code execution and configurations except allowing learners to run a Rails or Node server. It should be avoided in favor of explicit workspace configurations for a certain language or use case.
Migrating Default
If the workspace requires learner code to be run in the back-end (such as executing a Java or Python file), use those language-specific workspace types. If the workspace is used to serve HTML/CSS/front-end JS files with a web browser component, use the Static-Web workspace type.