Query rewrite allows Oracle to rewrite a query against the base table (in this case TEST_DATE) to use the materialized view (in this case TEST_SYS) transparently. That is highly useful when your materialized view is pre-aggregating data, for example. If I have a transactions table and a materialized view
CREATE MATERIALIZED VIEW mv_transaction_daily
REFRESH FORCE ON DEMAND
ENABLE QUERY REWRITE
AS
SELECT store_id,
transaction_day,
SUM(transaction_amount) total_transaction_amount
FROM transactions
GROUP BY store_id, transaction_day
then Oracle could transform a query like
SELECT store_id,
transaction_day,
SUM(transaction_amount) total_transaction_amount
FROM transactions
GROUP BY store_id, transaction_day
to use the materialized view rather than hitting the base table. And if you have appropriate dimension objects created, you could have a query like
SELECT store_id,
trunc(transaction_day,'MM'),
SUM(transaction_amount) monthly_transaction_amount
FROM transactions
GROUP BY store_id, trunc(transaction_day,'MM')
that could also be rewritten to use the materialized view rather than the base table.
If query rewrite is not enabled, you would only see a performance benefit from using the materialized view if you explicitly queried the materialized view rather than querying the base table. That generally requires more development effort and limits the ability of the DBAs to tune the application in the future by fine-tuning materialized views.
In your case, the presence of SYSDATE in your WHERE clause is going to prevent query rewrite because Oracle wouldn't be able to figure out that a query against TEST_DATE would actually be able to use the materialized view. For all Oracle knows, data in the materialized view that satisfied the condition when the materialized view was refreshed no longer satisfies the condition and data that didn't make it into the materialized view now satisfies the condition simply because the SYSDATE has changed.