Unit testing can cover many areas other than just data validation. For
example, a unit test can verify that if an invalid login occurs does the
browser display "invalid login".
Yes, of course the application would need to return an "invalid login"
message to the user. But where would you rather place the logic for
validating a login? In the application?
Or, might the application instead attempt to "record" a login (write to a
database table), then simply return an error message generated by the
database manager? So that validation occurs in the database, so to speak,
rather than in the application.
That way you keep the application logic simple, and let the heavy lifting
so to speak be handled by code which runs on the same server as the
database, and in the same address space as the database.
If you are validating a login against an IBM i user profile, that could be
performed by a "before" trigger too.
Or when a user submits the "forgot my
password" form does the resulting email produce a URL that resolves as
expected.
I'm not sure that I fully understand the use case. But wouldn't the same
principle apply? In other words, place code which implements business rules
such as sending an email to a use; have that run in a software component
that "knows" the user and his email account, because that software
component runs in the same address space as the database?
Again, simplify the module which may be supporting the user interface, by
placing code that queries and maintains the database, within the database,
again using ILE components.
Nathan.
As an Amazon Associate we earn from qualifying purchases.