Tests for Tutorial #2702

snqb · 2024-12-15T12:21:17Z

A userEvents-only run through the Tutorial.
Assumes desktop, as relies on keyboard shortctuts.
Goes through most steps(excluding mostly hint steps), ensures those and faithfully replicates a user going through the instructions.
0 dispatches used.

snqb · 2024-12-15T12:25:27Z

src/test-helpers/createTestApp.tsx

@@ -47,6 +47,9 @@ const createTestApp = async () => {
  })
 }

+/** Set up testing and mock document and window functions, and show tutorial. */
+export const createTestAppWithTutorial = () => createTestApp({ tutorial: true })


this, to preserve beforeEach(createTestApp) syntax

snqb · 2024-12-16T17:27:49Z

in proccess of fixing various errors, not much ready for review yet
will be soon, though

trevinhofmann

Looking good overall, @snqb. Thank you for the PR!

Just a few initial questions.

src/components/Tutorial/__tests__/Tutorial.ts

snqb · 2024-12-21T19:54:48Z

Hey, I've added some showcase of keyboard issues I've got.
Apparently, it's kind of tricky to cleanly create thoughts via userEvent.
We get insane results like this tree(got it via exportContext) after user.keyboard and user.type manipulations.

You can just run the tests via
yarn vitest src/components/Tutorial/ --project unit and tinker around with what's going on.

Below we have an almost-working test suite for the tutorial, where I'm stuck with this keyboard behavior, so you might want to have a look there, removing the .only from the first describe.

trevinhofmann · 2024-12-24T07:37:11Z

@snqb -- I've started tinkering with this. It seems that regardless of whether we use user.keyboard or user.type for the enter key, it's creating two thoughts:

(before)
- __ROOT__

(after)
- __ROOT__
  - 
  -

I also gave fireEevent.keyPress a try, but it doesn't seem to create a new thought at all:

(before)
- __ROOT__

(after)
- __ROOT__

This has me a bit perplexed, so I will take a look at it tomorrow with a fresh perspective.

trevinhofmann · 2024-12-28T00:44:21Z

Hi @snqb, I've been playing around with this issue without much success yet. Have you had a chance to look into it further?

snqb · 2024-12-28T01:35:10Z

I am really doubtful I can do more than I did, because this thing almost got me into a mental breakdown

What I suggest is: maybe we just do redux-way for these kinds of cases, preserving the rest userEvents style, and make a new issue on investigating why we have such problems with creating thoughts. And also, it generally feels like something worth a separate issue.
Thus, I could just fix this and, I believe one more issue, and we're good to mark this complete.

src/components/Tutorial/__tests__/Tutorial.ts

snqb · 2025-01-12T08:53:28Z

src/components/Tutorial/Tutorial2StepContextViewOpen.tsx

@@ -46,7 +46,7 @@ const Tutorial2StepContextViewOpen = () => {
      {TUTORIAL_CONTEXT1_PARENT[tutorialChoice]}" or "{TUTORIAL_CONTEXT2_PARENT[tutorialChoice]}" to show it again.
    </p>
  ) : contextViewClosed ? (
-    <p>Oops, somehow the context view was closed. Select "Relationships".</p>
+    <p>Oops, somehow the context view was closed. Select "{TUTORIAL_CONTEXT[tutorialChoice]}".</p>


it was a bug I've found while testing

snqb · 2025-01-12T08:54:17Z

.vscode/settings.json

+  "[typescript]": {
+    "editor.defaultFormatter": "esbenp.prettier-vscode"
+  },


files keep registering as typescript, not typescriptreact

is it fine we add typescript too?

Sure. I haven't run into any issues myself with the current configuration, but I don't think it can hurt.

snqb · 2025-01-12T08:59:38Z

src/components/Tutorial/TutorialNavigationButton.tsx

@@ -14,7 +14,6 @@ const TutorialNavigationButton = React.forwardRef<
 >(({ clickHandler, value, disabled = false, classes }, ref) => (
  <a
    className={cx(anchorButtonRecipe({ variableWidth: true, smallGapX: true }), classes)}
-    onClick={clickHandler}


it's duplicated by fastClick, which caused a skip of step I've painfully experienced multiple times while testing

Yes, good catch. It doesn't make sense to have both.

src/test-helpers/createTestApp.tsx

snqb · 2025-01-12T18:26:02Z

concerning the failing test:
it seems to be resolved if we manually await createTestApp, but I'm not really sure if we wanna do this

beforeEach(async () => {
  await createTestApp()
})

so the problem is with this case:

it('disable isLoading after initialize', async () => {
  expect(store.getState().isLoading).toBe(false)
})

isLoading keeps being undefined, while I haven't found a single use in our app where undefined is kinda possible via assignment, though it's possible judging from types in tutorial reducer.

/** Sets the Tutorial setting value. */
const tutorial = (state: State, { value }: { value?: boolean }) => {
  return ({
    ...settings(state, {
      key: 'Tutorial',
      value: value ? 'On' : 'Off',
    }),
    // disable isLoading when dismissing the tutorial, since we can assume this is a new thoughtspace or the thoughtspace has already been loaded
    isLoading: state.isLoading && value // <--- here `value` is `value?`, so it could leak 
    // it should be more of 
    isLoading: state.isLoading && value === true,
  })
}

but I haven't found at a glance a realistic way this could happen
so I judged, it's a create test thing

btw it really puzzles me that explicitly await-ing does lead to a different result
I assumed it kinda handles promises, as it works with all other cases.

beforeEach(async () => {
  await createTestApp()
})

raineorshine · 2025-01-12T19:01:26Z

Vitest passes a test context object to the beforeEach callback when written in point-free style: beforeEach(createTestApp). It was being ignored before, but now with the options object that was added, tutorial gets accidentally set to undefined. This gets passed down to isLoading through the tutorial action.

The point-free style is nice, so I would suggest just dispatching false explicitly when the tutorial should be closed.

Update: However, unless you emulate the user clicking "START TUTORIAL", you will have to explicitly set the tutorial to true.

      { type: 'tutorial', value: !!tutorial }

And have this reflected in the parameter type. Usually I declare options objects like this:

const createTestApp = async ({ tutorial } = { tutorial?: boolean } = {}) => {

trevinhofmann · 2025-01-14T07:01:31Z

@snqb -- Thank you again for the PR, as well as the latest updates. Please let me know when this is ready for review again, and I'll be sure to take a look right away.

snqb · 2025-01-14T09:46:15Z

@trevinhofmann hey, I think you can have a look.
I'm pretty satisfied with the final code, if we set the goal to have a very straightforward user-events based walkthrough.

trevinhofmann

Thank you, @snqb. Nice work! The updated tests cover all of the steps for the full tutorial (Parts I & II) with direct user interaction rather than manipulating the store. I've walked through each of the tests manually with the tutorial in the live app, and I'm satisfied with the test coverage.

raineorshine

Thanks, I think we have the right approach now!

src/components/Tutorial/__tests__/Tutorial.ts

raineorshine · 2025-01-15T14:17:41Z

src/components/Tutorial/__tests__/Tutorial.ts

+const user = userEvent.setup({ advanceTimers: jest.advanceTimersByTime })
+
+/** Get last created thought in the document, used mostly after `user.keyboard('{Enter}')`. */
+const lastThought = () => Array.from(document.querySelectorAll('[contenteditable="true"]')).at(-1)!


Let's use [aria-label="thought"] [contenteditable] or [data-editable="true"] to be a bit more specific. There happen to be no other contenteditable's on the screen, but it's a bit safer to not assume that.

Even better would be to specifically select the empty thought.

Even better would be to specifically select the empty thought.

I considered this during my previous review, but didn't mention it since the last thought and the empty thought were coincidentally always the same.

It would be nicer to explicitly select the thought to be edited (the empty thought), and easier to update in the future if we need to edit another thought during testing.

So, I arrived at

/** Get last created empty thought in the document. Gets the last thought that is not empty. Mostly used after `user.keyboard('{Enter}')` to get the new thought. */ const lastThought = () => Array.from(document.querySelectorAll('[data-editable="true"]')) .filter(it => !it.textContent) .at(-1)!

I think it works. Perhaps, a more refined solution could be out there, but it works :D
I'd prefer to modify this thing and move out to test-helpers at some point if we hit the wall, but not now.

raineorshine · 2025-01-15T14:26:31Z

src/components/Tutorial/__tests__/Tutorial.ts

+    ensureStep(TUTORIAL_STEP_FIRSTTHOUGHT_ENTER)
+    expect(screen.getByText('Now type something. Anything will do.')).toBeInTheDocument()
+    await user.type(lastThought(), 'my first thought')
+    await user.keyboard('{Enter}')
+    await act(vi.runOnlyPendingTimersAsync)
+  })
+
+  it('step second thought - prompts to add another thought', async () => {
+    expect(screen.getByText('Well done!')).toBeInTheDocument()
+    expect(screen.getByText(/Try adding another thought/)).toBeInTheDocument()
+    ensureStep(TUTORIAL_STEP_SECONDTHOUGHT)


Actions should generally be performed in the test that depends on them. So instead of typing and hitting enter in one test and asserting the result in the next, move the typing and hitting enter to the next test where it is asserted.

As a general rule, a test should end with an expect. Anything after that should probably belong to the next test.

I agree with this.

Some testing philosophies go further and recommend/require exactly one expect statement at the end of each test, but I believe that might be an excessively narrow rule for these tests.

raineorshine · 2025-01-15T14:27:06Z

src/components/Tutorial/__tests__/Tutorial.ts

+    ensureStep(TUTORIAL_STEP_FIRSTTHOUGHT)
+    expect(screen.getByText('Hit the Enter key to create a new thought.')).toBeInTheDocument()
+    await user.keyboard('{Enter}')
+    expect(screen.getByText('You did it!')).toBeInTheDocument()


Test actions look good and are very readable 👍

src/components/Tutorial/__tests__/Tutorial.ts

raineorshine · 2025-01-15T14:34:33Z

src/components/Tutorial/__tests__/Tutorial.ts

+  - `,
+    )
+
+    // Now I am going to show you how to add a thought within another thought.


This comment is redundant and can safely be removed.

Likewise with similar redundant comments below.

raineorshine · 2025-01-15T14:37:28Z

src/components/Tutorial/__tests__/Tutorial.ts

+    expect(screen.getByText(/Hit the Delete key to delete the current blank thought/)).toBeInTheDocument()
+    expect(screen.getByText(/Then hold the Ctrl key and hit the Enter key/)).toBeInTheDocument()


Let's stick with a single screen.getByText for a given point in the tutorial. Testing the minimal unique text at the given step will give us effectively the same test coverage, but will be less maintenance if the tutorial text is changed in the future.

Likewise in similar occurrences below.

@snqb Still needs attention

src/components/Tutorial/__tests__/Tutorial.ts

trevinhofmann · 2025-01-17T09:42:59Z

src/components/Tutorial/__tests__/Tutorial.ts

+    // we created a new thought on 3rd level, so we shift-tab our way back to root
+    await user.keyboard('{Enter}')
+    await user.keyboard('{Shift>}{Tab}{/Shift}')
+    await user.keyboard('{Shift>}{Tab}{/Shift}')


I don't mind this, but it might be more natural to select a thought at the root and create the new thought from there with one enter (and not use shift+tab).

Thoughts, @raineorshine?

Yes, I agree. Shift + Tab activates the Outdent command. It would be better to stick to simple navigation and New Thought commands for completing the tutorial. That way we can avoid coupling the tests to an unrelated command.

totally makes sense, thanks
now it's

await user.click(screen.getByText('Home')) await user.keyboard('{Enter}')

trevinhofmann · 2025-01-17T09:47:25Z

src/test-helpers/createTestApp.tsx

-      // skip tutorial
-      { type: 'tutorial', value: false },
+      // there are cases where we want to show tutorial on test runs, whilst mostly we don't
+      { type: 'tutorial', value: !!tutorial },


Instead of using !!tutorial to handle the undefined cases, it would be nicer to set a default value above so that the tutorial value is always a defined boolean.

FYI This is a small concession to allow point-free style in beforeEach.

See: #2702 (comment)

src/test-helpers/createTestApp.tsx

raineorshine · 2025-01-18T10:16:04Z

src/components/Tutorial/__tests__/Tutorial.ts

+const user = userEvent.setup({ advanceTimers: jest.advanceTimersByTime })
+
+/** Get last created empty thought in the document. Gets the last thought that is not empty. Mostly used after `user.keyboard('{Enter}')` to get the new thought. */
+const lastThought = () =>


Let's call this lastEmptyThought to better reflect the new functionality.

raineorshine · 2025-01-18T10:19:00Z

src/components/Tutorial/__tests__/Tutorial.ts

+// we should avoid using { delay: null }, and use jest.advanceTimersByTime instead
+const user = userEvent.setup({ advanceTimers: jest.advanceTimersByTime })
+
+/** Get last created empty thought in the document. Gets the last thought that is not empty. Mostly used after `user.keyboard('{Enter}')` to get the new thought. */


Gets the last thought that is not empty.

Maybe a typo on this part?

raineorshine · 2025-01-18T10:22:58Z

src/components/Tutorial/__tests__/Tutorial.ts

+    await user.type(lastThought(), 'third thought')
+    await user.keyboard('{Enter}')
+    await act(vi.runOnlyPendingTimersAsync)


There are still a few places where tests do not end in expect.

See: #2702 (comment)

raineorshine · 2025-01-18T10:24:52Z

src/components/Tutorial/__tests__/Tutorial.ts

+    expect(screen.getByText(/Hit the Delete key to delete the current blank thought/)).toBeInTheDocument()
+    expect(screen.getByText(/Then hold the Ctrl key and hit the Enter key/)).toBeInTheDocument()


@snqb Still needs attention

snqb · 2025-01-18T23:09:49Z

ok, I've rethought the thing and spent some time
but now almost everywhere we have one-expect-per suite
and it's kinda cleaner, pls have a look
I think it's all resolved

raineorshine

Thank you! I like the new structure. I think one expect at the end of each test is very clean.

raineorshine · 2025-01-19T08:57:52Z

src/components/Tutorial/__tests__/Tutorial.ts

+    .at(-1)!
+
+describe('Tutorial 1', async () => {
+  beforeEach(() => createTestApp({ tutorial: true }))


Maybe I'm missing something, but if the tests are all run sequentially on a single app instance, wouldn't this need to be beforeAll instead of beforeEach?

I really have not much idea how to make it work with one beforeAll, since if I don't create a new test app for each case, I'm left with empty-ish DOM
I think, the whole setup relies on re-creating an isolated testing env for each case, as it's done on every other test suite.

right now it's run with one db/store/state/whatever, but with cleaning up event listeners that keep attaching
but it's not one sequential run per se, though I'd argue it's a lot like reloading page at each step :D

I'm really not sure how to make it work with one beforeAll, really

Thanks for your reply. I'd like to dig a little deeper into this. The tests are quite readable right now, but it's not clear what state they share between test blocks.

I really have not much idea how to make it work with one beforeAll, since if I don't create a new test app for each case, I'm left with empty-ish DOM

What do you mean by "empty-ish DOM"?

I think, the whole setup relies on re-creating an isolated testing env for each case, as it's done on every other test suite.

Are you saying that the current implementation recreates an isolated testing environment for each case? Because my understanding is that these tests depend on the current test step being preserved between tests.

right now it's run with one db/store/state/whatever, but with cleaning up event listeners that keep attaching

The event listeners only keep attaching because you remove them and re-attach them each time.

but it's not one sequential run per se, though I'd argue it's a lot like reloading page at each step :D

Is it a sequential run or not? Or some hybrid? I think for clarity we need to stick with one or the other, or more carefully document the unique combination of shared state between test runs.

What do you mean by "empty-ish DOM"?

html <body data-browser="safari" data-color-mode="dark" data-device="desktop" data-drag-in-progress="false" data-native="false" data-platform="other" />

Are you saying that the current implementation recreates an isolated testing environment for each case? Because my understanding is that these tests depend on the current test step being preserved between tests.

we have everything in db, store etc., but dom is empty if we don't call the createTestApp on each test case
so the current approach, and me attaching and detaching events, is:

we createTestApp, get correct dom state, built from store/db.

we run tests

we remove event listeners created

Just runing a createTestApp once does not work, and it's a problem of our general testing environment.
It's easy to demonstrate if we try to do this:

we createTestApp

we run one test, where we create a thought "first"

we should have "first" thought present in our dom

but it does not work like this at all.
the test suite below gets 2/2 green, but it should not.

describe.only('T_T', () => { beforeAll(createTestApp) it('we create "first" thought', async () => { await user.keyboard('{Enter}') await user.type(lastEmptyThought(), 'first') await user.keyboard('{Enter}') expect(exportContext(store.getState(), HOME_TOKEN)).toEqual(`<ul> <li>__ROOT__ <ul> <li>first</li> <li></li> </ul> </li> </ul>`) expect(screen.getByText('first')).toBeInTheDocument() }) it('we expect to see "first" thought', () => { console.log(exportContext(store.getState(), HOME_TOKEN)) screen.debug(document.querySelector('.content')!) /* <-- prints this <body data-browser="safari" data-color-mode="dark" data-device="desktop" data-drag-in-progress="false" data-native="false" data-platform="other" /> */ expect(() => screen.getByText('first')).toThrow() }) })

maybe we should "fix" this, but will it break other tests?

i generally feel like this pr now achieves what we want it to, given the current testing environment
maybe we should create another issue for it?

Thanks. I'd love to figure out why the DOM is empty. Without knowing the answer to that, it's hard to know what the right call is here.

However, since all the tests pass and they are quite readable, I'm okay with merging the current implementation so that we have a good checkpoint in the commit history. We can investigate further in a separate issue.

If you could address the small stylistic changes below, then I'd be happy to merge. Thanks!

raineorshine · 2025-01-19T09:05:22Z

src/components/Tutorial/__tests__/Tutorial.ts

+    it('we can continue to advanced tutorial', async () => {
+      expect(screen.getByText('Learn more')).toBeInTheDocument()
+    })


There's a contradiction here: If the user just exited the tutorial, then how could the "Learn more" button be visible?

This seems to rely on the tutorial inadvertently being re-launched on beforeEach, which does not reflect real-world usage. We should make this more explicit, as it's not super obvious what's happening here, and closer to end-user behavior. I recommend one of the following options:

Don't click "Play on my own" at all. Then the test can click "Learn more" just as the user would. (less test coverage)

Click "Play on my own". Then navigate to the Help and start the second Tutorial as the user would. (more work, but more test coverage)

since I can do it, given the circumstances, I left it as is
at least it tests something that can break easily
and if we'll change our setup to have correct dom each time, this case will fail right away

(test of a test? xd)

raineorshine · 2025-01-19T09:06:25Z

src/components/Tutorial/__tests__/Tutorial.ts

+  beforeEach(() => createTestApp({ tutorial: true }))
+  afterEach(cleanupTestEventHandlers)
+  afterAll(cleanupTestApp)
+  it('we learn about context indicators', async () => {


It's more accurate to say "contexts" or "context view" than "context indicators". Let's update this to be more consistent with em terminology.

Likewise below.

raineorshine · 2025-01-19T09:15:27Z

src/components/Tutorial/__tests__/Tutorial.ts

+      expect(screen.getByText(/Add a thought with the text "To Do"/)).toBeInTheDocument()
+    })
+
+    it('we add a Home->To Do subthought', async () => {


Please use Home/To Do or Home • To Do to indicate subthought relationships. That will be a bit more consistent with our internal documentation, since -> is not used.

Likewise below.

snqb · 2025-01-19T16:56:28Z

I've updated the stylistics

snqb commented Dec 15, 2024

View reviewed changes

snqb marked this pull request as ready for review December 16, 2024 21:07

trevinhofmann self-requested a review December 17, 2024 00:21

trevinhofmann self-assigned this Dec 17, 2024

trevinhofmann requested changes Dec 17, 2024

View reviewed changes

src/components/Tutorial/__tests__/Tutorial.ts Outdated Show resolved Hide resolved

src/components/Tutorial/__tests__/Tutorial.ts Outdated Show resolved Hide resolved

src/components/Tutorial/__tests__/Tutorial.ts Outdated Show resolved Hide resolved

trevinhofmann assigned snqb and unassigned trevinhofmann Dec 19, 2024

trevinhofmann self-assigned this Dec 24, 2024

trevinhofmann reviewed Jan 1, 2025

View reviewed changes

src/components/Tutorial/__tests__/Tutorial.ts Outdated Show resolved Hide resolved

trevinhofmann removed their assignment Jan 1, 2025

snqb force-pushed the tests-for-gestures branch from 344061e to a100cb5 Compare January 12, 2025 08:52

snqb commented Jan 12, 2025

View reviewed changes

src/test-helpers/createTestApp.tsx Show resolved Hide resolved

snqb requested review from trevinhofmann and raineorshine January 12, 2025 09:00

snqb added 8 commits January 12, 2025 15:01

draft

3f522c1

lint

988f092

remove the useless case with gestures

8496e3a

fixes

29d2790

create just one user

34aa6df

use more user-like flow

46dcbd6

showcase keyboard behavior

fb9ecdd

lint

78dce26

typo

c6499ef

explicitly allow undefined tutorial

3b2b4f7

trevinhofmann assigned trevinhofmann and unassigned snqb Jan 15, 2025

trevinhofmann approved these changes Jan 15, 2025

View reviewed changes

trevinhofmann assigned raineorshine and unassigned trevinhofmann Jan 15, 2025

raineorshine requested changes Jan 15, 2025

View reviewed changes

trevinhofmann assigned snqb and unassigned raineorshine Jan 16, 2025

trevinhofmann reviewed Jan 17, 2025

View reviewed changes

src/test-helpers/createTestApp.tsx Show resolved Hide resolved

snqb added 3 commits January 17, 2025 18:51

remove ensuring steps

56c10ba

use data-editable=true & emptiness check for lastThought

cb0df78

address other smaller comments

7793de4

snqb requested a review from raineorshine January 17, 2025 13:19

raineorshine requested changes Jan 18, 2025

View reviewed changes

another wave of simplification

a42df99

snqb requested a review from raineorshine January 18, 2025 23:09

raineorshine requested changes Jan 19, 2025

View reviewed changes

more correct terminology

b2971a9

raineorshine approved these changes Jan 19, 2025

View reviewed changes

raineorshine merged commit 8126692 into cybersemics:main Jan 19, 2025
3 checks passed

		expect(screen.getByText(/Hit the Delete key to delete the current blank thought/)).toBeInTheDocument()
		expect(screen.getByText(/Then hold the Ctrl key and hit the Enter key/)).toBeInTheDocument()

Tests for Tutorial #2702

Tests for Tutorial #2702

Conversation

snqb commented Dec 15, 2024 • edited Loading

Choose a reason for hiding this comment

snqb commented Dec 16, 2024

trevinhofmann left a comment

Choose a reason for hiding this comment

snqb commented Dec 21, 2024

trevinhofmann commented Dec 24, 2024

trevinhofmann commented Dec 28, 2024

snqb commented Dec 28, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

snqb commented Jan 12, 2025 • edited Loading

raineorshine commented Jan 12, 2025 • edited Loading

trevinhofmann commented Jan 14, 2025

snqb commented Jan 14, 2025

trevinhofmann left a comment

Choose a reason for hiding this comment

raineorshine left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

raineorshine Jan 17, 2025 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

trevinhofmann Jan 17, 2025 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

snqb commented Jan 18, 2025

raineorshine left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

snqb Jan 19, 2025 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

snqb commented Jan 19, 2025

snqb commented Dec 15, 2024 •

edited

Loading

snqb commented Jan 12, 2025 •

edited

Loading

raineorshine commented Jan 12, 2025 •

edited

Loading

raineorshine Jan 17, 2025 •

edited

Loading

trevinhofmann Jan 17, 2025 •

edited

Loading

snqb Jan 19, 2025 •

edited

Loading