What should be the first code, functionality or validation?

Question

When coding, say, a registration form from scratch, does it make sense to first start it with the expected inputs, and then go back and capture / process unexpected inputs and deal with errors?

An alternative would be to process the input, check for any constraints and ensure that they are handled properly, and then work with the correct implementation of a typical use case.

One way is preferable to another, and if so, why? Also, is there an alternative way to solve this 2-part problem?

To clarify , in reality, I mean more than just checking data, including business rules, such as “No more than X people can register for this event”

Answer 1

The best thing, in my opinion, is to create a decent first version, which may not completely handle all unforeseen cases, but is done thoughtfully and modularly. Then you can go back and improve the logic so that your tests pass.

In the real world, this method pays off because you are most likely to be productive and interested when there is something that works with multiple kinks, instead of just getting stuck trying to understand all the edge cases in your head and solve them in the beginning.

Answer 2

One way is to use the TDD approach (assuming you write unit tests). Start by writing your unit tests, and then work on getting through these unit tests.

In my opinion, work with the user interface should be done last, since you probably have many opportunities to perform internal functions.

Answer 3

I highly recommend writing validators first. If you have something similar to work, it will be much harder to go back and add validators. By writing validators first (but not necessarily handling the exceptions that they raise), you will see that you have completed them. It also gives you a good chance to think about what you expect - it can help you come up with special cases that you will need to cover later.

Tracer bullets are good, but the principle should not apply to all aspects of the project.

Answer 4

• Write a test for a validation object method
• Write the method of the validation object
• Test before passage

Repeat 1-3 until all methods are tested.

4. Record the form and submit the data to the tested and working methods of the verification object.

Use the same procedure for a business object that processes data validation.

Answer 5

I always like to code the functionality first, and then add confirmation later. It seems that I understand very well that most encodings are performed in the development environment, and no one will send data while working on it.

But whatever way you feel comfortable is best.

The disadvantage of this method is that if you are disorganized, you may forget to add a fitness check or sanitation somewhere. And this happens :-)

Answer 6

If this is not too much work, I would start with a basic input check. Especially for dates or identifiers, such as order numbers. It is easier to loosen the test than to tighten it. Basic input validation can save a lot of debugging time in the backend.

On the other hand, let's say you are talking about a good Javascript validator that supports multiple languages. In this case, you better write a simple first version and create a backend based on this. You can polish the input form when it starts to approach the final version.

Answer 7

Once you get the functionality, will you REALLY come back and add a verification code?

Most of us would like to, but many of us ran out of time at the end of the project.

Answer 8

I’m not sure that the development of one or the other is superior ... Although Mr. Lickman says that bending the functional part, and then going back and doing the tedious work of regional affairs is more productive, I'm not sure that I see how.

Having functional code is not useful (and even dangerous) if you allow invalid values ​​(i.e. values ​​that your functional code did not expect).

Conversely, large border checks are useless if the values ​​that pass it are not processed in some way.

In a production environment, you really have nothing to show if you are not using both reality and functionality. The order in which you do this should really be a matter of personal preference. If you don’t feel creative and just want something tedious, write a code verification part. If you just realized that the ideal algo should do exactly what you need during a coffee break, sit down and write the functional part and return to the review later.

Answer 9

I like to assign a couple of useful functions, and then do validation checks for that function, and then check the rest and finally populate the rest of the functions.

Answer 10

If you break the code before the “model” and “user interface”, then some of them are easier to understand, but basically require a design choice: your model objects will assume the correct input and put a burden on the user interface or verify the input is correct.

Now, being a belt and a fit guy, I usually answer this question “yes”: the model will check the domain, even if the inputs must be checked in any case. But in any case, as soon as you make this decision, you will get the answer: if the domain check is part of the definition, you must build it and test it with all the other parts. If you separate domain verification from functionality, build and test them separately.

Answer 11

Having seen too many databases where people neglect verification methods, I vote for it.