Refactor update hook test cases

Committed.

Automatically closed - issue fixed for 2 weeks with no activity.

When working on [ ✨ Update hook 8102 should check for the existence of the field before trying to add it Closed: works as designed ] I noticed that between 2.1.3 and the current development, I noticed this issue changed the field definition in 8102 from hardcoded to pulling it from the schema. I've always learned that, although it might seem reasonable to do so from a DRY point of view, it is in fact discouraged because you can not be sure that the schema will always remain the same, which may lead to problems later on (I'm sure you can imagine scenario's, with field definitions changing multiple times and hook_update implementations trying to follow up those changes).

I've actually also seen people making this DRY by versioning the actual schema, so you have a honeypot_schema_8102() which is called both from honepot_schema as well as honeypot_update_8102. You're then free to keep honeypot_schema_8102() stable, while creating honeypot_schema_8105(), honeypot_schema_8110() or whatever when schema changes are needed (they could even call previous versions of the schema and modify those, although I'm not sure I like that particular variant, because it makes the current schema less clear).

Yes you're probably right.