H3 · POJO Serialization/Deserialization: POJO (Plain Old Java Object) deserialization BORROWS the `Bug` class you defined in B2 and REUSES it in test code — instead of manually r
POJO (Plain Old Java Object) deserialization BORROWS the `Bug` class you defined in B2 and REUSES it in test code — instead of manually reading the JSON the API PRODUCES field by field, you convert it to a Java object in ONE line with `.as(Bug.class)`. This is the most concrete example of the DRY (Don't Repeat Yourself) principle in API testing: the application code and test code SHARE the SAME class (`Bug`), so there is NO risk of inconsistency between them — if a field is added to the `Bug` class, the test code automatically "sees" it too (at compile time). So why is this more than just convenience? Because the line `Bug bug = response.as(Bug.class)` also INDIRECTLY tests that the response matches Java's TYPE SYSTEM — if a field type mismatches (like the "field type mismatch" contract defect from F5), this line throws an error AT RUNTIME. **For a deep POJO/serialization guide → see the `/rest-assured` page.**
Micro Lab: Code practice
Replace the TODO line with the critical line from the expected solution. This is not a real runtime; the goal is to reinforce writing the correct structure in a controlled way.
Step by Step: Code practice
Identify goal and input
Complete the critical line
Check output or behavior
Read the error message as evidence
Order the code reading and verification flow.
🎬 The Same Bug Class, in Two Worlds
Test: .as(Bug.class)
The `Bug` class written in B2 is used INSIDE the app, to carry data.
The API converts this class to JSON and returns it as the response.
The test code BORROWS the SAME `Bug` class and converts the JSON BACK into a Java object with `.as(Bug.class)` — the loop closes.