Comments (13)
Great, thanks!
Yes, all the endpoints need to be tested, except /api/firebase-config
in backend/routes/api/authentication.py
- this API route is no longer used and will be removed in the future. In the main
branch, goals.py
isn't a web route - it just contains functions. In the dashboard-page
branch, the functions in goals.py
are turned into API routes, but that'll only be ready when the branch is merged into main. So all the API routes in the following files need to be tested:
backend/routes/api/authentication.py
backend/routes/api/card_management.py
statistics.py
These are the only files containing API routes.
In terms of the endpoint tests, one part would be checking that the API accepts or rejects the right sort of data. But the priority would be that the API does what is expected when you pass it valid or extreme data. For example, when you go to the api/create-account
route, is an account created? Can you pass it any data which makes it behave differently than expected? Also, a priority would be to see what happens in different situations - for example, what happens when you try to get information from a user who doesn't exist?
A guide to how the code works, and for testing the code, is at CONTRIBUTING.md. You'll need to cloning the repo, and testing the local installation. Then you can set it to save to local .json
files rather than Firebase, which are easier to check if they have the right data. Then, the unit tests may be able to read these files. Also, you are free to change any classes to make it easier to test, so long as the code won't dramatically change - in particular, the database classes are relevant.
Feel free to ask me any questions about this, including about the CONTRIBUTING.md
guide - hopefully its easy to follow
Also, make sure that you write the code so that if you clone the repository, and run pytest testing/
, assuming requirements are installed, the tests will run. For example, if your tests rely on the code being setup so that it writes to a local file, the test should do this configuration first (in other words, changing the file that is used to determine whether the database is firebase or local). This is to replicate the process that the automatic pipeline that runs tests will make.
from dolphin-flashcard-app.
You can use any testing framework you like, so long as you add the packet to requirements.txt
(The pipeline, which automatically runs the tests, installs the packages in requirements.txt before running pytest)
from dolphin-flashcard-app.
Yeah, the second one would probably make the most sense
from dolphin-flashcard-app.
No - other than that, all the other endpoints just need a local database
from dolphin-flashcard-app.
Yes, i think you're free to close this issue.
Please let me know if there's something missing on the tests. 👍
from dolphin-flashcard-app.
I would love to help with this issue and this project.
I have some questions about this issue:
- All endpoints must have testing?
- How many different tests each endpoint must have?
Also, you can assing this issue to me if you want to.
from dolphin-flashcard-app.
Thanks for assigning me to this issue!
As soon as i get home, i plan to start to work on it.
from dolphin-flashcard-app.
Can i use any testing framework like unittest
, or should i use just assert
for this?
from dolphin-flashcard-app.
Hey, @jacob-macleod.
I'm wondering, how do you want these tests to be?
One method for each endpoint, with many assertions, like this:
def test_create_account(self) -> None:
valid_dummy = {
"userID": "1",
"displayName": "Dummy"
}
response = self.post_api(Routes.ROUTE_CREATE_ACCOUNT['url'], valid_dummy)
response_json = response[0]
self.assertTrue(expr=response_json['success'],
msg=f'Invalid return for "create_account" method. '
f'Should be True but was {response_json['success']}')
error_dummy = {
"userID": "",
"displayName": ""
}
response = self.post_api(Routes.ROUTE_CREATE_ACCOUNT['url'], error_dummy)
response_json = response[0]
self.assertFalse(expr=response_json['success'],
msg='Invalid return for "create_account" method, should not create a nameless user.')
Or should I split each assertion on different methods?
def test_create_valid_account(self) -> None:
valid_dummy = {
"userID": "1",
"displayName": "Dummy"
}
response = self.post_api(Routes.ROUTE_CREATE_ACCOUNT['url'], valid_dummy)
response_json = response[0]
self.assertTrue(expr=response_json['success'],
msg=f'Invalid return for "create_account" method. '
f'Should be True but was {response_json['success']}')
def test_create_invalid_account(self) -> None:
error_dummy = {
"userID": "",
"displayName": ""
}
response = self.post_api(Routes.ROUTE_CREATE_ACCOUNT['url'], error_dummy)
response_json = response[0]
self.assertFalse(expr=response_json['success'],
msg='Invalid return for "create_account" method, should not create a nameless user.')
The second way is verbose and specific, the first one will stop on the first AssertionError
on the method.
Particularly, i think the second way is more organized, easier to understand and to find the problem:
from dolphin-flashcard-app.
Perfect, the backend-testing branch has already some unitary tests.
Here is the branch i'm currently working on, the file test_api.py
has the most changes, and the unittests come just after test_check_request_json
method.
If you want any specific test, just let me know. 👍
from dolphin-flashcard-app.
Looks good, thanks!
Just one point, the serve_credentials function doesn't need to be tested, because its not being used anymore and will be removed in the future.
I see by the function for that, you have some comments relating to setting up a test firebase instance. Because the tests are run automatically in a pipeline, the instance would have to be integrated into the pipeline. There are two possible ways - either having a pipeline stage where test instance credentials are saved from github secrets, like the real credentials in the current pipeline, or by deploying some sort of testing deployment of the code connected to firebase, and testing that. Of course, that's outside the main scope of this issue, so you don't have to explore that - it would be a secondary thing, possibly needing a separate issue.
from dolphin-flashcard-app.
The comment you saw about a firebase instance was exactly about the serve_credentials
function, i forgot that you said that it does not need to be tested.
Besides this function, do you think i'm gonna need a Firebase instace on my local development environment?
I commented that because there was no other function that had no local database connection.
I'm wondering if it's possible to test all the endpoints using just the local database config.
from dolphin-flashcard-app.
@jaymeklein is this issue completed now - am I free to close it?
from dolphin-flashcard-app.
Related Issues (20)
- Add mobile support for flashcard overview page
- Implement card operations menu for flashcard overview page HOT 5
- Add the ability to create a folder HOT 4
- Add the ability to create a flashcard HOT 2
- Add the ability to search for flashcards
- Design and implement switch to firestore HOT 1
- Convert Documentation to Mintlify HOT 18
- Develop Edit Flashcards Page HOT 2
- Add the ability to delete cards
- Implement the Study Flashcards Page HOT 1
- Develop Sign In/Landing Page HOT 2
- Develop Dashboard Page HOT 1
- Fix pipeline error and improve code base accessibility HOT 3
- Improve issues
- Develop API route for Total XP HOT 3
- KeyError on create-account endpoint (local database config) HOT 2
- TypeError on create_flashcard endpoint (regex) HOT 2
- get-flashcard endpoint is returning None, regardless of given data HOT 3
- Unhandled exception on calculate_streak endpoint HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from dolphin-flashcard-app.