QA: test - user registration backend api

[mtreacy002]

Description

test cases for Register user API

Fixes #54

Type of Change:

• Quality Assurance

Code/Quality Assurance Only

• New feature (non-breaking change which adds functionality pre-approved by mentors)

How Has This Been Tested?

• by running python -m unittest discover tests on the terminal
• by running tests from Python and Tests explorers VSCode
  Both resulted in pass

Note: To test the register UI-backend integration/functionality manually, you MUST run BIT frontend server with the PR#24 latest code otherwise it will not work.

Checklist:

• My PR follows the style guidelines of this project
• I have performed a self-review of my own code or materials

Code/Quality Assurance Only

• My changes generate no new warnings
• My PR currently breaks something (fix or feature that would cause existing functionality to not work as expected)
• I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes

Additional Note:
Travis-build failed but caused by unrelated issue (can't create test database through Travis)

[mtreacy002]

@anitab-org/bridgeintech-maintainers , can you please advice if this is ok? only done one test for now coz I want to see if it's ok before writing the next test cases. Also, there's issue with travis build as i mentioned above. can you pls guide me on how to troubleshoot this?

[mtreacy002]

Update @anitab-org/bridgeintech-maintainers . Here's the latest test cases (minus Internal server error)

will add that soon.

The tests done locally has passed successfully

[mtreacy002]

I just realized that the response from ConnectionError using the old code will get display in its original HTTP response (unmasked ~ not a customised response from BIT or MS). This is the standard HTTP with json data in them.

With old code:

With latest code (masked response)

So, I'm just fixing the actual code at the same time (thanks to testing, we catch the bug early) 😂.

Although just now I changed the code back to matching old code for Exception error since this type of error will have a json response in it.

I just didn't have time to write a test for this random exception since my focus is to test the listed items first for the time constraint sake.

cc @anitab-org/bridgeintech-maintainers

[meenakshi-dhanani]

I have checked the tests covered(good coverage) and the Travis build is also passing.

[meenakshi-dhanani]

@ramitsawhney27 can you review?

[mtreacy002]

I have checked the tests covered(good coverage) and the Travis build is also passing.

Thanks, @meenakshi-dhanani for your review. 😉

[mtreacy002]

Update @anitab-org/bridgeintech-maintainers. I've just added validation check to Register user functionality. forgot to put it there for some reason 😊

[ramitsawhney27]

Line gaps seem inconsistent.

[mtreacy002]

yep, fixed it now.

[mtreacy002]

Is this ok for code readability? since the line shows separation of logic. or should I put all logic together without line gaps?

[mtreacy002]

Update @anitab-org/bridgeintech-maintainers. I've modified all the requested changes. Can you please re-review? Thanks

[mtreacy002]

@meenakshi-dhanani , I've just push the latest change as per your request. Can you please re-review? Thanks

[meenakshi-dhanani]

Why did we need to force push? Not sure. It could be a separate commit

[meenakshi-dhanani]

Travis build passes. Tests coverage looks fine to me and code has been reviewed by Ramit.

[meenakshi-dhanani]

@ramitsawhney27 can you re-review? There was just a formatting change I had asked for. I think that's why you might need to review again

[mtreacy002]

Why did we need to force push? Not sure. It could be a separate commit

Like I mentioned in our call last night, since I opened new branch from develop to work on namedtuple, I need to pull rebase from this PR #59 branch and PR #60 to make sure my changes for the name tuple won't break the register functionality and its tests. If both PR I pull (59 and 60) have separate commits, those commits from 2 separate branches will intermingle based on whichever got committed first, and it won't be clear where individual commit coming from. That's why I squashed commits into one on each PR and pull rebase it from my namedtuple branch. You can see from the screenshot below:

Can you see why it's better to squash commits in this case? As you can see, it is clear where the commits are coming from (PR #59 Register, #56 from develop branch #60 Test Register). If I left commits separately from PR59 and PR60 branches, you'll see lots of small commits scattered everywhere and not sure where they're coming from (I knew this coz that's the issue I used to face when I started a new PR on top of code base of another PR that is still being reviewed). since I squash merge, this intertwined commits no longer an issue.

[foongminwong]

Just want to drop a comment here

The changes made in this PR were tested locally. Following are the results:

1. All possible responses are tested below:

   • Running tests for user regsitration backend api locally
     Screenshot/gif/url:

     Expected Result: The unittest for user registration abckend api should run succecssfully.
     Actual Result: Got an error: psycopg2.errors.InvalidSchemaName: schema "bitschema" does not exist LINE 2: CREATE TABLE bitschema.personal_backgrounds (....

     

2. Additional comments/notes:

   • Since you have screenshots showing that the test cases are running successfully on your end, I'm guessing something's wrong on my database setup. Will figure out why it can't find the bitschema (I thought I already set them up on the pgAdmin/Postgre)

3. OS Version: Windows 10

[mtreacy002]

@foongminwong . Try to set the search path on your bit_schema_test database (actually set search path for both bit_schema and bit_schema_test) from your command line, just like what Meena and I did in the travis script below

[meenakshi-dhanani]

Why did we need to force push? Not sure. It could be a separate commit

Like I mentioned in our call last night, since I opened new branch from develop to work on namedtuple, I need to pull rebase from this PR #59 branch and PR #60 to make sure my changes for the name tuple won't break the register functionality and its tests. If both PR I pull (59 and 60) have separate commits, those commits from 2 separate branches will intermingle based on whichever got committed first, and it won't be clear where individual commit coming from. That's why I squashed commits into one on each PR and pull rebase it from my namedtuple branch. You can see from the screenshot below:

Can you see why it's better to squash commits in this case? As you can see, it is clear where the commits are coming from (PR #59 Register, #56 from develop branch #60 Test Register). If I left commits separately from PR59 and PR60 branches, you'll see lots of small commits scattered everywhere and not sure where they're coming from (I knew this coz that's the issue I used to face when I started a new PR on top of code base of another PR that is still being reviewed). since I squash merge, this intertwined commits no longer an issue.

Problem with small commits scattered everywhere - Let's understand why small commits are important. They help your code become easier to understand, basically dividing your work into small parts. The problem with these being scattered is because they might belong to different PRs, in that case what we usually do is establish a commit format, eg.

[PR #]

so you can always look at a commit and know what PR it is referring to.

About why the small commits might not look that good, is because the messages are not meaningful. If a message is meaningful and indicative of intent, it's always useful to look at those small commits.

In teams and projects, since multiple things are being developed in parallel, you will have occasions when there's a sequence such as this:

#A
#B
#A

There is no need to squash all A's together. And force push and change this. The reality is that work is being done in a parallel fashion, let your history show that.

Conclusion: Have clean commit messages, stick to a format. At work we often use

[mtreacy002]

Ok. I'll do it moving forward then. Thanks for the advice, @meenakshi-dhanani 😉

[mtreacy002]

Update @anitab-org/bridgeintech-maintainers. I have pull rebased the recent merged to develop branch on this PR.