Merge branch 'learning-software-engineering:main' into main

Topics/Software_Engineering.md

@@ -4,7 +4,7 @@ Potential topics--
 
 1. Methodologies & Frameworks
     1. Agile
-        1. Scrum
+        1. [Scrum](./Software_Engineering/Scrum.md)
            1. [User Stories](./Software_Engineering/User_Stories.md)
         2. Kanban
         3. XP

Topics/Software_Engineering/Scrum.md

@@ -0,0 +1,78 @@
+## Scrum Framework
+
+### Table of Contents
+- [What is scrum?](#what-is-scrum)
+- [Scrum values](#scrum-values)
+- [Members of a scrum team](#members-of-a-scrum-team)
+- [What are sprints?](#what-are-sprints)
+- [Scrum artifacts](#scrum-artifacts)
+- [Scrum ceremonies](#scrum-ceremonies)
+- [Why is scrum important?](#why-is-scrum-important)
+- [Resources](#resources)
+
+### What is scrum?
+Scrum is an agile project management framework that helps teams organize and manage their work. While most often used in software development teams, this framework applies to different sectors in HR, accounting, finance, etc. The term for this framework was coined from the 1986 Harvard Business Review article in which the authors compared high-performing teams to the scrum formation used in rugby. Scrum specifies artifacts, ceremonies/events, and roles associated with each sprint to get work done. 
+
+### Scrum values
+- Commitment
+    - Team members should make sure not to overcommit to the amount of work they can complete and should be committed to their time-based tasks.
+- Courage
+    - Team members should have the courage to question processes and ask open, challenging questions about anything that hinders the ability to progress.
+- Focus
+    - The team should be focused on their selected tasks to complete the specified work within a sprint.
+- Openness
+    - There should be regular meetings, such as daily standups, to openly talk about progress and blockers.
+    - The team should be open to new ideas.
+- Respect
+    - Everyone should recognize a team member's contributions and accomplishments. 
+    - Respect for one another is essential to ensure mutual collaboration and cooperation.
+
+### Members of a scrum team
+A scrum team consists of three specific roles:
+- Product owner:
+    - The product owner is the expert in understanding the business, customer, and marketing needs.
+    - They focus on ensuring the development team delivers the most value to the business.
+- Scrum master:
+    - The scrum master coaches the team and organizes/schedules resources for scrum meetings. 
+    - Their goal is to optimize the flow for the scrum team to ensure maximal productivity and minimal blockers.
+- Development team:
+    - The development team is the ones who work on creating the product/working on items in the sprint, according to the specifications from the product owner. 
+    - The team includes developers, UX specialists, Ops engineers, testers, and designers. 
+    - With these differing skill sets, the team can cross-train each other to prevent bottlenecks.
+
+### What are sprints?
+A sprint is a short duration where the scrum team works to complete a specified amount of work. Sprints usually correspond to some set of features a team wants to add. The goal of a sprint varies from team to team, some goals being a finished product accessible to customers and others being to complete a subsection of a larger product. The usual timeline for a sprint is two weeks, but the timeline varies between teams. 
+
+### Scrum artifacts
+Scrum artifacts refer to the information a scrum team uses that details information about the product in development, the tasks involved in a sprint cycle, and the end goal. 
+- Product backlog:
+    - The product backlog is the primary list of work that needs to be done and is maintained and updated by the product owner or manager.
+- Sprint backlog:
+    - The sprint backlog is the list of user stories or bug fixes that should be done by the end of the current sprint cycle and chosen from the product backlog.
+- Increment (sprint goal):
+    - The increment is the end product of a sprint. 
+    - The increment can mean a finished product, features usable to customers by the end of the sprint, or a completed section of a larger project.
+
+### Scrum ceremonies
+The scrum framework incorporates regular meetings and events that teams perform regularly. In scrum, there are five regularly held events:
+- Backlog organization:
+    - This is the responsibility of the product owner, who makes sure to continually update and maintain the product backlog, according to feedback from users and the development team.
+- Sprint planning:
+    - This meeting is led by the scrum master and includes the development team, where the items to be completed during the sprint are added from the product backlog per the sprint goal.
+- Sprint:
+    - This is the time period where the scrum team works to complete items in the scope of the sprint.
+- Daily standup:
+    - The standup is a regularly scheduled meeting in which members of the team will update members on their progress and mention blockers they are facing with their work.
+- Sprint review:
+    - This occurs at the end of the sprint, where the team meets to demo the end product and showcase the completed sprint backlog items.
+- Sprint retrospective: 
+    - Also occurring at the end of the sprint, the retro is where the team discusses the aspects of the sprint that worked and parts that could use improvement.
+    - This builds in feedback and continual improvement of processes in the scrum framework.
+
+### Why is scrum important?
+Teams use the scrum framework since it provides an efficient and adaptable way to organize and manage teams and products. It is team-centric and self-managed and encourages creativity with the flexibility to assign work based on work styles. The framework has concrete roles, events, artifacts, and values. These aspects of scrum are incorporated into professional workplaces and can be used in CSC301 to finish the project in the short amount of time given. 
+
+### Resources
+- [Atlassin - scrum](https://www.atlassian.com/agile/scrum)
+- [AWS - scrum](https://aws.amazon.com/what-is/scrum/)
+- [Techtarget - scrum](https://www.techtarget.com/searchsoftwarequality/definition/Scrum)

Topics/Tech_Stacks.md

@@ -17,3 +17,4 @@
 ### [Learning Nodemailer](./Tech_Stacks/Nodemailer.md)
 ### [React Components Guide](./Tech_Stacks/React_Components.md)
 ### [Temporal For Workflow Orchestration](./Tech_Stacks/Temporal.md)
+### [Learning Cypress](./Tech_Stacks/Cypress.md)

Topics/Tech_Stacks/Cypress.md

@@ -0,0 +1,108 @@
+# E2E Testing with Cypress
+
+- [Cypress Introduction](#cypress-introduction)
+- [Why do end to end testing?](#why-do-end-to-end-testing-)
+- [Why Cypress?](#why-cypress-)
+- [Installation and setup:](#installation-and-setup-)
+- [The basics](#the-basics)
+- [Best Practices](#best-practices)
+
+## Cypress Introduction
+
+Cypress is mainly used for testing web applications, especially those built in javascript. It provides an interface to programatically test your application, and visually what went wrong (or right) in tests. This page will primarily focus on E2E (end-to-end) testing with cypress rather than component testing.
+
+## Why do end to end testing?  
+
+[https://circleci.com/blog/what-is-end-to-end-testing/](https://circleci.com/blog/what-is-end-to-end-testing/)
+
+The above link has a good explanation on what end to end testing is and why it should be used. While other types of tests like unit tests or functional tests make sure a single component/module works as expected, an end to end test starts from the perspective of the end user and tries to mimic what an end user would do when accessing your application. 
+
+Cypress very closely mimics a real user, think of it as a robot accessing your website from a browser like a human would, but you can program the robot to interact with your website however you like and programmatically check the output on the screen.
+
+## Why Cypress?
+
+There exist many different testing frameworks online, such as [Selenium](https://www.selenium.dev/), [Jest](https://jestjs.io/), [Mocha](https://mochajs.org/), and more. 
+
+Cypress is most useful for UI, integration and end-to-end testing, so it can be used in tandem with unit testing frameworks like Jest. 
+
+Cypress is built on top of mocha, and uses its framework for tests as well. The main difference is that cypress focuses more on improving client-side and UI tests. 
+
+Selenium is often compared to Cypress, due to it being one of the most popular UI testing frameworks before Cypress was created. One of the biggest differences is that Cypress automatically retries commands while waiting for DOM elements to load properly, helping to prevent [flaky tests](https://www.jetbrains.com/teamcity/ci-cd-guide/concepts/flaky-tests/) and eliminating the need to write wait or sleep helpers that were needed in Selenium. Cypress is also faster and easier to get setup and start creating tests than Selenium. However, Selenium is more flexible, allowing for testing in multiple browsers at a time, and also for writing tests in languages other than javascript. 
+
+## Installation and setup:  
+
+Cypress can be automatically installed with [npm](https://www.npmjs.com/): `npm install cypress`
+
+See [https://docs.cypress.io/guides/getting-started/installing-cypress](https://docs.cypress.io/guides/getting-started/installing-cypress) for more details.
+
+To run cypress, we can use the command `npx cypress open` and follow the instructions provided on the UI. 
+
+See [https://docs.cypress.io/guides/getting-started/opening-the-app](https://docs.cypress.io/guides/getting-started/opening-the-app) for more details.
+
+## The basics
+
+Cypress has an extremely detailed guide for getting started, explains how to create and run tests, and there is also a lot of information linked as well.
+
+[https://docs.cypress.io/guides/end-to-end-testing/writing-your-first-end-to-end-test](https://docs.cypress.io/guides/end-to-end-testing/writing-your-first-end-to-end-test)
+
+[https://docs.cypress.io/guides/core-concepts/introduction-to-cypress](https://docs.cypress.io/guides/core-concepts/introduction-to-cypress)
+
+I highly recommend reading through the above two links, and the entirety of the core concepts section in the documentation. It gives a thorough introduction on how cypress works and how to use it to test your application.
+
+The first link provides a detailed guide on how cypress commands work and how to read the testing UI. 
+
+The second link provides a guide to most of the commonly used functions in cypress, like how to query for elements, check if they have or not have a specific property, actions such as clicking on buttons or filling out forms, and more. 
+
+## Best Practices
+
+One common use case for cypress (and UI testing in general) is to test responsiveness, does the UI look like it should in different viewports?
+
+While it is possible to duplicate tests, this may cause you to need to repeat large parts of the code to select elements and fill out forms, which has nothing to do with 
+
+It is much easier to use the beforeEach() hook and a cypress context() to bundle viewpoints together. As an example: 
+
+```javascript
+viewports = [{“name”: “small”, “dim”: [300, 800]}, 
+			{“name”: “large”, “dim": [300, 800]]
+
+viewports.forEach(viewport => {
+	cy.context(“Viewport” + viewport.name, () => {
+		cy.beforeEach(() => {  
+			cy.viewport(viewport.dim[0], viewport.dim[1])  
+		})  
+		//tests go here  
+	})
+}
+```
+In tests, you can include snippets of code like  
+```javascript
+if (viewport.name == ‘small’) {  
+	cy.get("@somedivmobileonly").should('exist')
+} else if (viewport.name == 'large') {
+	cy.get("@somedivmobileonly").should('not.exist')
+} 
+```
+
+Another common test for responsiveness is checking the alignment of items, for example testing that one element should be above another in a small viewport and beside another in a larger viewport. 
+
+In this case, you should use a closure (described in the [variables and aliases](https://docs.cypress.io/guides/core-concepts/variables-and-aliases) section) to store the first element's position: 
+
+```javascript
+cy.get('elem1').then($elem => {
+	cy.get('elem2').then($elem2 => {
+		let p1 = $elem.position()
+		let p2 = $elem2.position()
+		if (viewport.name == 'small') {
+			expect(p1.top).to.be.greaterThan(p2.top)
+			expect(p1.left).to.be.equal(p2.left)
+		} else {
+			expect(p1.top).to.be.equal(p1.top)
+			expect(p1.left).to.be.greaterThan(p1.left)
+		}
+	})
+})
+```
+
+Note the use of `expect` instead of `should`, since we are not chaining off of a cypress command we use an assertion instead. See [here](https://docs.cypress.io/guides/references/assertions) for other assertions. 
+
+For more, Cypress provides their own list of best practices here: [https://docs.cypress.io/guides/references/best-practices](https://docs.cypress.io/guides/references/best-practices). I highly recommend reading their guide, if I had known about this before, I would have saved a lot of effort learning the hard way what not to do.