feat: DHIS2-9276 #12 - e2e tests for working lists - #1402
Conversation
JoakimSM
changed the title
| <Table | ||
| className={classes.table} | ||
| data-test="dhis2-capture-event-list-table" | ||
| data-test="online-list-table" |
There was a problem hiding this comment.
Making a change to this data test attribute since this component is used for both events and teis. @vilkg (will be merged to master soon)
| </Head> | ||
| <Body | ||
| data-test="dhis2-capture-event-list-body" | ||
| data-test="online-list-body" |
| return { | ||
| sortById: column.id, | ||
| sortByDirection: 'desc', | ||
| sortByDirection: getSortDirection(column.type), |
There was a problem hiding this comment.
minor functionality change.
There was a problem hiding this comment.
Looks good thanks for adding the tests Joakim! 🙏
I wanted to say that is good effort that we are trying to follow the text whenever is possible. And you have been doing that here in most cases.
Also wanted to make one comment as a general observation of mine. To me, since these tests are e2e (meaning testing from an end user perspective) seems counter intuitive that we are testing for requests being returned from the api. Users when they navigate through an application they dont know about api responses. They understand if something work by its looks. Generally this is why that article suggested we want to test against text being visible on the screen, because a user interface is broken from an end user perspective when certain views arent being displayed or displayed with wrong information.
Now one question might be, why we wanna these e2e tests to be written from a user perspective? Imagine that we have a migration from an endpoint to another. Lets say we are migrating from an endpoint that used to be /api/events/ to one that is now being renamed to /api/trackerEvents/. Ideally we would like to make the migration and run the tests to see if all the scenarios we used to cover in the e2e tests are still running alright after the migration.
I assume you had good reasons for testing against the api. However you might find useful keeping this perspective I am describing in mind when writing these tests.
|
@paschalidi Sorry, I totally missed your comment here. Thanks for the comment, this was really valuable feedback for me 👍 I lost the user perspective here somewhat. Did some reading to get my head straight and a SO comment about functional testing hit the nail on the head for me:
So I believe many of my tests here by this definition is considered integration tests. Anyway, I actually forgot about this PR when I merged the tei working lists earlier today, so I will close this one and create a new reworked PR. Let's have a chat about this tomorrow if you have time. |
|
@JoakimSM yep would be up for a chat for sure :) Take it easy 👍 |
2 participants
Cypress tests for tei and single event working lists.