In the prior episode, we started out our coding of a solution for a specific case. Now we move on to the general case problem-solving code. Some of this work may have been completed in your general solution, but it is worth looking over these to craft the best solution.
Input Parameters
Our hard-coded solution did not need any parameters or even user input. However, as we move into the code for the general case problem-solving, we need to add those features. It is possible to skip the user input step at this time and merely hardcode different values for the problem. I do not recommend this as it is better to get some user input steps in early so they can be tested extensively during implementation.
Security and Validation
As we move to a more flexible solution, we need to consider security and validation. User input can be insecure or incorrect. This is an excellent time to start implementing checks that the data is valid and the user is authorized to enter it. We are just getting started on this facet of the implementation, so a lot of placeholder code makes perfect sense for now.
More Testing
Your tests were pretty simple last time. Now we are building out the core functionality and should verify it through testing. We will follow some general rule of thumb steps for testing.
- Max value in a range
- Min value in a range
- one off values of both min and max in a range
- Empty values
- Values that are too long
There will often be additional testing required to ensure you have not “broken” your application. However, these are a good start.
Your Homework
Keep moving forward on the implementation phase of your application. We hard-coded our way through the last bit of homework. Now, it is time to break up some of those tightly defined values and allow for user input. Usability is not the concern yet. Stay focused on functionality and solving the problem. We will make it pretty later in this phase.
