In the previous step, we have learned how to write and run a first set of (arguably not very sophisticated) tests. Now it's time to share them with the world, while at the same time making sure that something bad happening to our machine doesn't result in a loss of our work. Let's bring our code under version control.
The remainder of this step is assuming that you are using Git as your version control system, as most of the software development world is using Git. If, for some reason, your company is using another version control system, such as Subversion, most of the information below should still apply.
First, we need to create a new 'home' for our code, a place where other developers can find it and contribute to it. This place is typically called a remote repository.
Typical places to create these remote repositories are GitHub, GitLab and Bitbucket. Some application lifecycle management platforms, like Azure DevOps, also provide a place to store and access your code.
Next, we need to identify our project as a local repository (git init) and link our local repository to our remote repository (git remote add).
This is also a great time to tell your version control system what files to bring under version control, and what files to ignore. Some examples of files that should be ignored are
- Output generated by running our code (compiled code, reports, etc.)
- Caching and temporary files
- Binaries (please stop including browser drivers in your source control)
Git enables you to do this using a .gitignore file. If you're not familiar with these files, this is a great time to learn more about them.
The final step is to synchronize your remote repository, which is empty still, with what's in your local repository (i.e., your test code). When using Git, that's a three-step process:
- Staging changes in local files using
git add - Creating a commit that bundles changes into a single, atomic 'transaction' using
git commit - Pushing commits from your local to your remote repository using
git push
For other version control systems, the mechanics will look a little different, but the purpose is the same: you're looking to synchronize your remote repository so it reflects the current state of your local repository.
Well, yes and no. There's more, much more to learn about version control systems in general, and about Git specifically. That's outside the scope of this project, though. If you want to learn more about Git, here's a great, free video course specifically geared towards managing test code.
You have now:
- Created a local and a remote repository
- Brought your code under version control
In the next step, we are going to create a small CI pipeline that will run our tests automatically for us whenever we push new changes in our project code to our remote repository.