I noticed some easy-to-reach code that were not being covered in the
test suite.
in the process, I also found a bug with the PUT method for the user
( update user information ) which would fail because a model method was
~not implemented. I could not find any references to it in the history~
~either ( it could also be that I didn't look hard enough ). I implemented~
~the function and wrote the test for the method.~
missing. this was because Sequelize renamed the findById method to
findByPk in v5. this was missed during the upgrade from v4 to v5 in
a14cd84.
also while implementing the test for the PUT method for the user, I
wondered what would happen if I attempted to change the email of the
user since we use the user's email as the primary key.
while the request processed successfully, the email address field was
not updated which is good. shouldn't we throw some kind of error in
those scenarios though?
I'm not sure what should be done in such scenarios, hence I didn't
include that in the update data for the user. I'm currently only
changing the name of the user. if an error condition is supposed to be
triggered ( and if it is not implemented ), I can add the code for it.
I noticed some easy-to-reach code that were not being covered in the test suite.
in the process, I also found a bug with the
PUT
method for the user ( update user information ) which would fail because a model method was ~not implemented. I could not find any references to it in the history~ ~either ( it could also be that I didn't look hard enough ). I implemented~ ~the function and wrote the test for the method.~ missing. this was because Sequelize renamed thefindById
method tofindByPk
in v5. this was missed during the upgrade from v4 to v5 in a14cd84.also while implementing the test for the
PUT
method for the user, I wondered what would happen if I attempted to change the email of the user since we use the user's email as the primary key. while the request processed successfully, the email address field was not updated which is good. shouldn't we throw some kind of error in those scenarios though? I'm not sure what should be done in such scenarios, hence I didn't include that in the update data for the user. I'm currently only changing the name of the user. if an error condition is supposed to be triggered ( and if it is not implemented ), I can add the code for it.code coverage report
$ npm run test-rest-with-coverage
before
after
unchanged