Devs + QA

[manishapriya94]

Goal

Our challenge is to make the Amplify App for robust. Security is just as important to advocacy groups as it is to us.
Priorities:

• Apple Pay integration in Checkout
• API tests for Google Civic, Lob, and Auth0 API
• Building an ORM

Table of Contents

• App Context
• Framework and Tests
• User Journey
• Logic Model
• Data Structure
• Getting Started
  • Features

Context:

GMT20220129-002704_Recording_as_1680x956.mp4

Throughout this hackathon, we're going to be going from a single page app structure

To abstracting and implementing the database as well as several other APIs

Our framework: Test Driven Development

Security modeling should be something we think across the SDLC, especially at the time of commitment. Although we have CodeQL and other scanning tools - buildsafes, bugs, and other QA concerns need you. Our goal is to have a unit and integration test across functions and API integrations. Learn more here:

Types of Tests (We use Jest):

Read More

Unit: Unit tests cover blocks of code to ensure they run without problems. A tested unit can be a function, a module, a class. Unit tests should be isolated and independent of each other. For a given input, unit test checks the result. It can help you make sure that individual parts of your applications work as expected by finding problems early and avoiding regressions.

Integration tests:
Even if all your unit test pass, it still just means that the parts are working well on their own. Still, the application might fail. Integration tests cover cross-module processes, where individual modules are combined and tested while working together. Thanks to them you can provide a way to ensure that your code works well as a whole.

• Fix repo-wide integration test bug: Integration Tests Failing in CI #263

Add a regression test/fix a bug
Read More

• Add a regression test
• Fix the bug
• Find variants and fix them too

The purpose of regression testing is to make sure that you never make the same mistake twice. When you fix a bug, you should add a regression test, which is designed to fail if the same bug is ever reintroduced. I don’t think regression testing is controversial, but it often feels like a waste of time to write a test for a bug that you already fixed. Realistically, how likely is it that somebody will ever reintroduce the exact same bug? It’s a tempting step to skip if you’re in a hurry. These are the reasons why I think it’s important:

Proof that the bug is fixed. I like to add the regression test as the first commit, before the commit that fixes the bug, so that I can easily confirm that the test fails without the bug fix and succeeds with it.
Code coverage. Bug fixes often add a new if-condition to the code. The regression test ensures that the new code has coverage. If a future developer is tempted to remove the if-condition because they don’t understand what it’s for, then the test will fail.
Improving the fuzzing corpus. Fuzzers work best with a corpus of sample inputs. In the case of Exiv2, the files in the test/data subdirectory are also useful as a corpus. Every time we add a new regression test, we are improving the quality of the corpus.

User Journey

Constituent: Our main bases of end users of this platform are constituents found across. They are motivated by convenience, updates, and their role within their community.

Advocacy Groups: Are looking to make it easy for their requests for change understood, looking at data of how users are interacting with issues

• Stage 1: Users are being sent onboarding via advocacy groups - preview and Auth0 authentication
• Stage 2: User reviews letter, adds validation and sends payment
• Stage 3: User has successfully send letter and/or donated and is added to notification channels

Logic Model explaining interaction between client side, server, database, and APIs

Resources

• Wikis on current API use

Data Structures

Campaigns
This is the major data table we use to onboard every advocacy

id is the key identifier as there can be multiple orgs to one campaign
organization is an array of strings of the orgs behind a particular advocacy
name the name of the advocacy
cause the area the cause focuses on
page_url refers to the main site hosting the information to learn more about said cause
letters_counter how many letters have been sent to date

• need to add a picture_url for campaign card
• a description column
• letters_goal column

letter_versions
This data is sent to Lob, primarily template_id which is specific to each campaign by office division.
This data structure triages the letter object that's being displayed and sent, specific to the template_id of the region that's being picked by the office.
​​

keyID: use to create join or belong relationships for Users, Campaigns, and Letters sent
template_id: lob html template
office_division: each campaign has a different letter dependent on filter. Federal is the default.
state: Custom versions per state
county: Custom versions per county
CampaignID: maps to campaigns table

Constituent Table: (not yet being used in signname.vue)

• Letters sent holds id of letter that was successfully posted with Lob (payment and address verification went through)
• User agreement is a boolean that they abide by the platforms outlined community safety and protection guidelines
• Updates is sending campaign_id so that we can send to advocacy groups so they can follow up and by our user education team
• Street address, City, and State are strings
• Zipcode is a string

Getting Started

• Pick someone to pair with across the hackathon (Backend + QA + Frontent)
• Pick a feature (has specification for frontend, backend, qa)
  • frontend will be working out of these Vue components and design elements found in Figma
  • backend will be working through api routes here
  • QA has tests for lob and google civic api here
• Look at Wiki to implement and review data structures above
• Essentials of Vue
  • frontend vuetify elements
  • backend component testing

Pick a feature

• Browse cause: home page, select campaign
• Browse Reps: select one in your zipcode
• Choose Rep: Select to preview letter
• Authenticate: Go through Auth0 and see full action accordion
• Review Letter: customize your letter
• Validate address: sign name and address/get updates
• Select donation: add the amount to donate
• Pay and Send: add in payment info and send letter
• Action complete): celebrate the change you made and invite others

[manishapriya94]

Browse Causes

User Journey

This layout assumes that we are a landing point from a call to action that an advocacy group puts out on social media, email blasts, and other comms - but not the first time the constituent is hearing about the cause.

That's why we are letting the campaigns be a simple gallery while the landing page is where there is more context per the campaign requests.

Open Issues (by priority)

🖼 Frontend: user is inputting based off a cause based design	🗃 Backend: routing to the cause campaign page
Filter button by causes	ORM implementation
Add campaign button	Post function to update additions to Campaign Table
Bug: Awkward word-wrapping for campaign names	Refresh the constituent table in database

[manishapriya94]

Browse Representatives

User Journey

This feature has the user enter their zipcode and select the government scale they wish to work within, and returns a list of representatives for their causes, as well as (in the future) showing other reps running for the same cause.

The decision to input only zipcode is partially due to how the Google Civic API is set up. The scope will be constricted based on the jurisdiction the campaign letters apply to

[manishapriya94]

Choose Representative

User Journey

• User input displays local, state and federal representatives
• Clicking on a representative will give you a preview of the letter

🖼 Frontend: user picks a representative to display a jurisdiction specific advocacy letter	🗃Backend: triages campaigns database to Lob API template_id for frontend
search_rep displays array of reps	google civic api provides the following information in representatives.js
selection triggers preview	integration testing
filter by level of office

[manishapriya94]

Review Letter

User Story
Allows user to review information and add their own experiences as it relates to topics being discussed

🖼 Frontend: user reviews and customizes letter input	🗃 Backend: tracks any changes in the letter object	⚙️ QA: integration tests for Lob
Completed
Displaying the letter: retrieve the template_id from Lob to display letter version per jurisdiction selected	Using Lob API to return html to preview based off of campaign template_id	integration testing
To do
[ ] create custom text box	Use Lob API to define letter template with the least cardinality
[ ] text to speech	Appending the letter: use append function to change template_id object for letter object
[ ] language translator

[manishapriya94]

Validate Address

User Story:

• As a constituent, I add my address so my jurisdiction can be validated and my advocacy holds weight
• As a constituent, I can also sign up to hear updates about this cause further via text

🖼 Frontend: user reviews and customizes letter input	🗃 Backend: tracks any changes in the letter object	⚙️ QA: integration tests for Lob
Completed
SignName.Vue has input fields which are passed to backend	stores constituent personal info about user in Lob addressbook (GDPR compliance)	integration testing
	address verification function ensures address is valid	Lob currently tests for verifying address and addressbook entries with error codes
To do
Save user number using SMS api	shift to storing information in constituent table	What other Lob error codes can we test for?
[ ] text to speech	Appending the letter: use append function to change template_id object for letter object
[ ] language translator

Frontend:

• Lob with the parameters reflecting addressbook
• Save user number using SMS api
• Integrate twilio routes

Backend

• Currently
• Once an ORM is implemented, we will

QA

• What other error codes can we test for?

[manishapriya94]

Select Donation

User stories:

• Constituent pays a default of 1.00 (close to a forever stamp) which offsets the use of APIs like Lob, Stripe, and Cicero to mail the letter
• Constituent can select a donation amount to support their cause further
• A progress bar creates a visual incentive of the goal to support

Frontend:
DonateMoney.vue will pass along the donation amount selected as an item

• Add Apple Pay into Checkout UI
• Coupon code

Backend
Checkout.js will process the payment intent

• Integrate Apple Pay into checkout flow

QA

• In tests Add tests for integration requests and webhooks

[manishapriya94]

Finalize Checkout & Send Letter

User Story

• User has clicked pay and send letter button and enters payment information to ensure letter is sent

Frontend:

• Checkout.vue uses the Stripe Checkout UI kit
• coupon codes allow us to subsidize costs for people who wouldn't be able to send the letter other wise
• Stripe frontend checkout redirection.
  Backend:
• Successful payment creates a lob post request
• Address verification makes sure constituent address is valid
• implement backend stripe checkout flow. 213
  QA:
• Lob currently is tested for letter template and the above functions, are there other unit tests you can think of?

[manishapriya94]

Action Complete

User Story:

• User arrives to action complete to see how they moved the needle
• reminded of options to repeat actions for other causes or invite a friend

Frontend:

• If payment and lob request are succesful, we arrive at actioncomplete.vue
• Header and progress bar reflects new letter value
• CauseCarousel.vue lists other causes from campaigns that could be a good fit by cause_type
• Social referral widget
• Issue 215: Finish ActionComplete page
  QA:
  Stripe API errors that reroute if unsuccessful payment?
  Backend
• Letter_count within campaigns table is updated by 1
• Progress bar is updated to reflect letter_count from campaigns