1a. Gray box testing is the intermediary between black-box and white-box testing.

Unlike
black-box testing, some knowledge of the implementation and internal structure of the code is
required, but not a completely transparent, in-depth view like white-box testing. Generally,
gray-box testing is more time-consuming than black box testing, as some elements of the code
itself are considered, but less than white-box testing. Finally, compared to white/black-box
testing, the focus is generally on the interoperability of system components, which can include
how data is structured within the database to how data is sent between different services.

1b.
I. Web applications generally have many asynchronous components in which data is shared
between different components in a non-consecutive fashion. As a result, certain operations
have to wait a non-predefined amount of time for the reception of data and handle cases where
the data received may be unexpected or lost. These asynchronous problems necessitate a
different testing methodology.

Ii. Web applications are generally not built in a single monolithic architecture, but rather many
different components and services for storing data, handling requests, load balancing, etc. With
this service architecture, a large concern in testing web applications is if some change in a
service may break the interoperability with other services that depend on that one. As a result,
some sort of integration testing must take place between services to prevent these regressions
for occurring.

2a.
The important considerations for this architecture is validating whether a certain request has the
correct permissions in order to perform a certain action. Whenever a request is received, that
request would contain a token, which would confirm what the identity of the entity making the
request is (Identity Validator). There are two main umbrellas of commands -- a set of commands
to interact with articles and a set of commands to create/approve user accounts. The two nested
boxes correspond to the controller methods that would perform the necessary database queries
(Article Query/Identity Query) depending on the action. These commands in the middle boxes
perform the higher-level processing of the command, such as validating whether or not the input
is formatted correctly, and the Query boxes perform the lower-level processing of constructing
the query and sending it off to the database.

2b.

(a) Query components can be created by validating if the resultant query after running the
function matches what is expected.
(b) Subsequently, additional tests can be run by mocking a test database schema and
running the query while testing if the database successfully changes expectedly.
(c) Identity Validator can be tested by setting up a mock database with test users, and
running identity validation with various tokens to check for valid output.
(d) Main controller functions (middle-section) can be tested by mocking the Query function
outputs, and test if the functions successfully handle success and failure states.
(e) User Interface can be tested with a UI testing framework such as Selenium, testing
whether the HTML output is correct after page interaction.
2c.

(a) Selenium - provides a mechanism for testing whether or not the HTML is as expected
after performing page state change or input.
(b) PHPUnit - individual components of the architecture can be tested with unit tests, while
mocking the output of other dependent classes incrementally.
(c) tSQLt - unit testing framework for SQL; provides easy method for running transactions
while testing whether the database has been modified expectedly.