chore(arpa_reporter): add decision report for testing library

docs/decisions/0011-use-testing-library-vue.md

@@ -0,0 +1,96 @@
+# 0011. Use testing-library/vue
+
+Date: 2024-12-11
+Status: Proposed <!-- Proposed | Accepted | Rejected | Superceded -->
+
+## Context and Problem Statement
+
+Accessibility is a key aspect to development and testing-library supports testing from the user perspective using accessible selectors.  testing-library is also a widely used testing library that can make achieving test case coverage easier.
+
+## Decision Drivers <!-- optional -->
+
+- [driver 1, e.g., a force, facing concern, …]
+- [driver 2, e.g., a force, facing concern, …]
+- … <!-- numbers of drivers can vary -->
+
+## Considered Options
+
+- Do not make any changes to the testing libraries 
+- Use vitest browser testing locators 
+- … <!-- numbers of options can vary -->
+
+## Decision Outcome
+
+TBD
+
+### Positive Consequences <!-- optional -->
+
+- Tests better reflect the user experience 
+- Tests check for accessible names
+- Provides a better developer experience 
+
+### Negative Consequences <!-- optional -->
+
+- May require some ramp up time for devs who are not familiar with testing-library approach to testing. 
+- …
+
+## Pros and Cons of the Options <!-- optional -->
+
+### Do not make any changes to the current test libraries and version
+
+[example | description | pointer to more information | …] <!-- optional -->
+
+- Good, because no changes to current tooling 
+- Bad, because it is harder to test in a way that catches accessible names and achieve test case coverage
+- … <!-- numbers of pros and cons can vary -->
+
+### Use vitest browser testing locators 
+
+[example | description | pointer to more information | …] <!-- optional -->
+
+- Good, because it continues to rely on vitest 
+- Good, because under the hood, it uses testing-library
+- Bad, because it is only available in browser testing mode and requires playwright to be installed
+- Bad, because it required an separate script from the current test script
+- Bad, because it generated separate coverage report which would need to be reconciled with the current test report to calculate total code coverage
+- … <!-- numbers of pros and cons can vary -->
+
+### [option 3]
+
+[example | description | pointer to more information | …] <!-- optional -->
+
+- Good, because [argument a]
+- Good, because [argument b]
+- Bad, because [argument c]
+- … <!-- numbers of pros and cons can vary -->
+
+## Code Examples
+
+[If relevant / it would help the discussion, please provide code examples here that would help in comparing the various options on the table.
+
+A few possible options for doing this:
+
+- A link to a gist or proof of concept repository
+- A separate code block using [github code fencing](https://help.github.com/articles/creating-and-highlighting-code-blocks/)
+- If necessary, you can add a new folder within the `docs/decisions` directory titled `000X-decision-name-files` and add necessary code files there.
+Ideally use the same mechanism for storing all files related to a decision - the below examples are meant to show the full set of different options
+]
+
+### Option 1 Code Example <!-- optional -->
+
+```javascript
+console.log('Hello, World!');
+```
+
+### Option 2 Code Example <!-- optional -->
+
+[Link to gist](www.example.com)
+
+### Option 3 Code Example <!-- optional -->
+
+[local link to file](000X-decision-name-files/example.js)
+
+## Links <!-- optional -->
+
+- [Link type](link to adr) <!-- example: Refined by [xxx](yyyymmdd-xxx.md) -->
+- … <!-- numbers of links can vary -->