# How to set up your dev environment for Ironic - Tips and Tricks
## Setting up the environment.
```
# Note: TBD. Link to the project's documentation for now.
```
Here's how the contributor docs of the ironic project recommend you create an environment.
```
# create separate env for ironic work (do once)
virtualenv -p python3 $HOME/envs/ironic-env
# activate the environment (whenever working on ironic)
source $HOME/envs/ironic-env/bin/activate
# Close the environment (when done working or switching to something else)
deactivate
```
With the `ironic-env` active, installing necessary packages is as simple as usual pip install.
```
# for running unit-tests and code-formatting checks
pip install tox
# other project requirements
pip install -r ironic/requirements.txt
# Note: In the above command just replace `ironic` with the path to your ironic project directory
```
[(source)](https://docs.openstack.org/openstacksdk/latest/contributor/setup.html)
This is very useful. I'll add my own tips for streamlining the work flow below soon.
### Tip-1: Use an alias
Doing `source ~/envs/ironic-env/bin/activate` every time is pretty inconvenient.
Especially when you have multiple project environments in `~/envs`.
Add a bash alias to get to your environment quicker, like so:
```
echo "alias ironic-env='source ~/envs/ironic-env/bin/activate'" >> ~/.bashrc
```
Next time, when you open the terminal, typing just `ironic-env` will activate your environment.
## Tests (tox) shortcuts.
So, you just made a little (or big) modification to a file.
The first thing you should do next is to write some accompanying tests.
Usually this is to see
* i) if your change actually works as you intended,
* ii) to test how it behaves under 'weird' scenarios.
You want to make sure that errors are handled gracefully (or failed hard at, depending on design).
Say you made some changes at `./conductor/node.py`
For the above file, we would write our unit tests in `./tests/unit/conductor/test_node.py`
We use a project's directory like structure for tests, just one level under the tests directory.
Okay done, you have your tests, and you have the modification you made. Now how to test?
We'll use tox for that. We installed it earlier in the [above](#setting-up-the-environment) section.
### Basic unit tests + specifying smaller test runs
Basic way to do unit tests is:
```
tox -e py3
```
You might have seen the above in the [contributor docs]. This will run all the tests it finds under unit tests directory.
This takes a looong time. You can narrow down the tests to save time. For example
```
tox -e -- ironic.tests.unit.conductor
tox -e -- ironic.tests.unit.conductor.test_node
```
How did we get this magic incantation? Just replace '/' in the directory structure with '.'
You can also go a level deep into files, to test specific classes.
Just like how you would do imports in python.
[contributor docs]: https://docs.openstack.org/openstacksdk/latest/contributor/testing.html#unit-tests
### Code Formatting
Openstack/ironic requires your code to conform to formatting guidelines described in [pep8].
To see if you are doing so and to get suggestions on how to fix discrepancies, run the pep8 test.
```
tox -e pep8
```
[pep8]: https://www.python.org/dev/peps/pep-0008/
### Re-run only failing tests
Sometimes you may find yourself repeating running tests, while making small changes trying to fix your code that's failing.
At such times, you may find the `--failing` option useful.
```
tox -e -- --failing
```
This reruns **only** those tests that failed in the previous test-run.
You can keep repeating it until you've fixed all those bugs.
**Remember** to do a full test run after to make sure you've not introduced any new bugs.
Since the `--failing` option only runs unit tests that failed previously,
if you introduce a bug, you won't know about it until you re-run the previously successful tests again.
---