IT Project Testing === --- ### Why? --- ### Because you want to be lazy - Automating testing saves you from doing more work later - Gives assurance - more confidence in code correctness - Reduces developer mental overhead ... - Stops bugs hitting prod --- ### Categories - Unit - Integration - Functional - End to End - Acceptance - Performance - Smoke --- ### Unit (front/back) Lowest level of testing, here you want to test a single function / method for correctness. Cheap, quick and useful for checking correctness of **important** functions. e.g. ```python def test_validate_email(self): self.assertFalse(invalid_email("k@github.com")) self.assertTrue(invalid_email("gg.com")) self.assertFalse(invalid_email("a@student.com")) ``` --- ### Integration (usually back) Verify multiple moving parts are interacting correctly e.g. does the API return 200s when we request stuff and 201 when we create - Does upload a photo return 201 - Does authenticate work - Does incorrect form data/missing required fields return a 400 bad request --- ### Functional (usually back) Similar to integration, however instead of just checking whether high level everything is working together, we check here whether the functional requirements are operating correctly. E.g. If i create a user does my api correctly allow for further queries to modify their email? - Can you create a user, then query that user and see them there - Can you upload an article, then see the article there (API) - ... ``` expect(body.id).toBe("some_id") ``` --- ### End To End (front/back) Replicates user behaviour, usually using something like selenium you mock user interactions and ensure correctness. These require the most effort, provide the most information. Probably a good idea for you "KEY" user flows if you are a bit ahead. --- ### Performance (front/back) AB Testing - how many can your server handle.... not really important for this because unelss you notice a performance issue e.g. each page takes more than 2 seconds to load etc then its not really something to worry about with the small number of users --- ### Acceptance (front/back) Similar to functional, except end to end, this is usually when you want to combine a whole heap of stuff and if they dont pass > 99% then a change doesnt get approved for merge. You dont need to worry about this so much. --- ### Smoke Test (usually front) My favorite test! component.didRender()? It costs like 4 lines of code and provides you with an instant notification if your app is completely broken or backend can't spin up the server. --- ### What to focus on **Unit Test** Any important function (like email verification) should have unit test with a few test-cases including fail and success scenarios. **Integration / Functional** Very effective at identifying bugs, unwanted behaviour. Saves you a LOT of time in manually testing your changes! I would say have at least a few for each major endpoint/backend request. --- ### How - Unit - Super simple, google the framework / language your are using e.g. ``` nodejs unit test tutorial ``` And then go for it. Remember don't test stuff that doesn't need it, if its a complicated piece of logic that your application hinges on then yes. Test. --- ### How - Functional & Integration Can go two routes here, either we mock the DB or we deploy a canary app and test that. I'm going to assume that you're **not** willing to run staging and production environments as I wouldnt (it's overkill but cool) be so probably mocking is the best bet. --- ### How - Functional & Integration (1) If you've been testing your API with postman you can export the tests and run them with newman in any CI/CD tool, given you adequately setup a database mocking tool (2) You can mock requests with http-mocks or any library that supports this. This will then get run in the CI/CD tool --- ### Example gh ... --- ### Other stuff to mention Do all, none or some of this. It's purely my thoughts and by no means correct, incorrect or otherwise. - [x] Planning - Requirements - [x] Motivational Modelling (do-be-feel) - [x] Functional Requirements & Non-Functional - [x] MVP outlined: what you're going to do --- - [x] Planning - Sprint - [x] MVP (sprint 1) ticketed out - [x] Relevant information added to all tickets --- - [ ] Planning - Frontend - [ ] Designs for key pages? Figma/Wireframe - [ ] Only to help your actual product/client. This doesn't do anything if you never code up the actual stuff. --- - [x] Planning - Architecture - [x] API endpoints listed w/ payloads - [x] Draft outline of frontend/api/cdn etc --- - [ ] Testing (only if you are ahead) - [ ] Unit tests for important functions - [ ] Mocked intergration/functional tests for endpoint stuff --- - [ ] CI/CD/Deploy - [ ] Deployed - [ ] Automatic Deployment - [ ] Automatic Testing on Deploy - [ ] Automatic Deploy on Merge --- - [x] Product - [x] MVP Done? Meet basic criteria e.g. upload stuff, edit page and share? --- ### Useful stuff [Atlassian Guide to Software Testing for CI/CD](https://www.atlassian.com/continuous-delivery/software-testing) [Running E2E Tests with GH Actions](https://medium.com/tomorrowapp/running-end-to-end-tests-with-github-actions-d45b70c032e6) [Newman/postman automanted testing](https://medium.com/@soufianebouchaa/automated-testing-for-github-actions-newman-automation-from-postman-e50b9c923692)