From 3a00dfb49d8ca486daf975cc0eccc71c8cafe7a6 Mon Sep 17 00:00:00 2001 From: Michael Park Date: Wed, 15 Mar 2023 08:47:39 +0000 Subject: [PATCH] feat(pages): add pages on environments, testing, the tech test --- guides/environments.md | 51 ++++++++++++++++++++- guides/interview/preparatory-explanation.md | 36 ++++++++++++++- guides/testing.md | 16 +++++++ 3 files changed, 100 insertions(+), 3 deletions(-) diff --git a/guides/environments.md b/guides/environments.md index e5228f7..93f8142 100644 --- a/guides/environments.md +++ b/guides/environments.md @@ -3,9 +3,56 @@ When not dictated to by a client the following environment definitions should be applied: -## TODO - - `local` - your local machine - `dev` - `staging` - `production` + +The environment can be controlled through environmental variables and loaded in +respect to the product that needs them. They can be listed in Github Actions, +Dockerfiles, or even can be loaded within the code (which is very common). + +An example of how one may do this in python for example: + +```python +import os + +ENV = os.environ.get("ENV") # Load the environment variable from the machine it's on +``` + +Because the code above is referencing the variable `ENV`, this variable will +need to be set on the machine that the code is running on. This can be stored in +a `.envrc` variable if you are using `direnv` on your local machine. Or added to +the Databricks cluster that you are deploying (For example). Environment +variables are used in all of our projects, and they should be used to ensure +that the code running pertains to the correct environment that it is suited for. + +## Development Stages/Environments + +The four different environments are generally self explanatory and splitting out +dev and staging may be overkill for certain projects but in general: + +### Dev + +A safe deployment that allows for experimentation and should be used for +testing, debugging and ensuring that code is ready for deployments. Initial +feature development will be easiest in this environment. + +### Testing + +A deployment that is to run ahead of the production release by x amount of +days/weeks to ensure that UAT testing by QA (Quality Assurance) engineers on new +features can be accepted before deployment to production. + +### Pre-Production/Staging + +The battle tested and thoroughly safeguarded deployment that is the one that can +be treated as a beta environment to do any final checks and testing. It is an +exact mirror of production apart from the incremental change that will be going +forward. The focus is to test the application from start to finish and ensure +behaviour of the entire product. + +### Production + +The battle tested and thoroughly safeguarded deployment that is the one that is +used by the client/customers. diff --git a/guides/interview/preparatory-explanation.md b/guides/interview/preparatory-explanation.md index e4ca458..a9ce4f9 100644 --- a/guides/interview/preparatory-explanation.md +++ b/guides/interview/preparatory-explanation.md @@ -17,7 +17,7 @@ least a passing familiarity with the format of the technical assessment. The below must be shared with the candidate prior to the interview itself: -- the technical assessment will take place using +- The technical assessment will take place using [GitPod](https://www.gitpod.io/), a web-based IDE similar in appearance and functionality to [Visual Studio Code](https://code.visualstudio.com/). If they are familiar with GitHub's @@ -27,3 +27,37 @@ The below must be shared with the candidate prior to the interview itself: implemented in a language agreed with the candidate. - the tests will initially be failing and the aim of the assessment is to add or update the existing code such that the tests pass. + +## Tech Test Example + +The first question on our tech-test is the following (if taking the test in +`python`): + +If you choose to research our company and read through our guides on the +handbook we think that you should be allowed to see what kind of questions to +expect on the test. There are four more questions beyond this one (with a bonus +one if you get that far) and they get more challenging as they go along. + +```python +def test_01_can_count_number_of_males(): + """ + Count of the number of males in the rows of data from + the provided records object below by changing the logic in the function + get_count() found in app.py + + Hint: Make sure the function gets something to count! + """ + + records: Records = [ + Record(first_name="mitchell", surname="clausson", dob="21/01/1980", sex="m"), + Record(first_name="thomas", surname="skindstad", dob="18/06/1988", sex="m"), + Record(first_name="susan", surname="boyle", dob="01/04/1961", sex="f"), + ] + + actual_value_1 = get_count() + + assert actual_value_1 == 2 +``` + +In this test we are looking to test your knowledge of classes and their +attributes, as well as the ability to search a list by some criteria. diff --git a/guides/testing.md b/guides/testing.md index e69de29..f3cd93d 100644 --- a/guides/testing.md +++ b/guides/testing.md @@ -0,0 +1,16 @@ +# Testing + +Make sure that the tests in the codebase are correct, sensible, and useful. +Tests do not test themselves, and we rarely write tests for our tests—a human +must ensure that tests are valid. + +Will the tests actually fail when the code is broken? If the code changes +beneath them, will they start producing false positives? Does each test make +simple and useful assertions? Are the tests separated appropriately between +different test methods? + +Remember that tests are also code that has to be maintained. Don’t accept +complexity in tests just because they are not part of the main product/binary. +If there are ways to compartmentalise behaviour into smaller and more +predictable chunks, it is advised to do so as it makes it easier for product +maintainers to understand expected behaviour.