Our tests are failing because our API is actually writing the (invalid) profile objects into the database; conversely, we expect our API to respond with a 400 error. Therefore, we must implement additional validation steps for the profile subdocument.

Currently, we are using if conditional blocks to validate the email and password fields. If we use the same approach for our new user object, we'd have to write a very long list of if statements, which is bad for readability. One may also argue that our current implementation of the validation function is already quite unreadable, because it's not immediately obvious what the user object should look like. Therefore, we need to find a better approach.

A more declarative way of validating is to use a schema, which is just a formal way of describing a data structure. After a schema is defined, we can use validation libraries to test the request payload against the schema, and respond with an appropriate error message if it does not pass.

Therefore, in this section, we are going to use a schema to validate our profile object, and then refactor all of our existing validation code to use schema-based validation as well.