Expand and improve iteminfo_tests

[wapcaplet]

Summary

SUMMARY: Infrastructure "Improve test suite for item info panel"

Purpose of change

Add more (and better) test cases to tests/iteminfo_test.cpp

Some of my recent PRs have affected the item info panel, quite a critical and central component of the Cataclysm gaming experience. Feeling a sense of responsibility to add tests for my contributions (and a sense of disappointment at how few tests already existed), I've determined to improve the test coverage for this component.

Describe the solution

Add TEST_CASEs for major parts of the item info panel that were not yet tested. Items were chosen for being common in-game, and having qualities that I guess are unlikely to change.

New tests include:

• item description and physical attributes
  • gallon jug: "A standard plastic jug ..." (with Category, Price, Volume, Weight, and Material)
• weapon attributes, attack ratings and moves
  • Halligan bar: Bash 20, Cut 5, To-hit +2, Moves per attack 145
• techniques when wielded
  • Halligan bar: Brutal strike, Sweep Attack, Block
• ranged weapon attributes:
  • crossbow: Reload time, Fire modes, Mods (in addition to existing Capacity/Ammo/Damage tests)
• food freshness:
  • pine nuts: "This food looks as fresh as it can be" or "This food looks old"
• item conductivity
  • plank: "This item does not conduct electricity"
  • pipe: "This item conducts electricity"
• list of item qualities
  • screwdriver: "Has level 1 screw driving quality."
  • Halligan bar: "Has level 1 digging quality. Has level 2 hammering quality. Has level 4 prying quality."
• repairability and with what tools
  • longshirt: Repaired with: bone needle, wooden needle, sewing kit, or tailor's kit
  • Halligan bar: Repaired with: extended toolset, arc welder, or makeshift arc welder
  • hazmat suit: Repaired with: soldering iron or extended toolset
  • rock: This item is not repairable.
• description flags
  • Halligan bar: This item can be clipped onto a belt loop; As a weapon this item is well-made
  • hazmat suit: This gear completely protects you from (electric discharges, any gas, radiation), worn over clothing, keeps you dry

Describe alternatives you've considered

All of these tests depend on the specific attributes and qualities of in-game items, and as such may be quite fragile. If any future contributor rebalances the Halligan bar damage, or tweaks the flags on the hazmat suit, some of these tests are probably going to fail. In other words, the tests are strongly content-dependent.

For a more robust set of tests, it would be preferable to populate the tests/data/ directory with a hierarchy of JSON files specifically for use by the test cases. Here is where I would put a "Test Halligan bar" and "Test hazmat suit" item JSON that iteminfo_test.cpp would load, and use for all of its formatting expectations. This would keep the tests focused on functionality, rather than content. Getting a system like that in place (and making it easy to use for new contributors) sounds like a minor project in itself, so I decided not to get sidetracked on figuring that out for this PR.

These test cases are by no means comprehensive. The item info panel shows a ton of stuff, and I've only scraped the surface of what I know could be shown in different circumstances. Complete coverage was not something I considered tackling with this PR either.

Testing

Building and running test cases with make (...) && tests/cata_test [iteminfo]

Additional context

Essentially done now, allowing time for review and feedback.

The basic theme of this PR is to test that each portion of item information is displayed, formatted, and color-coded as expected. For example, almost everything in this Halligan bar screenshot is covered by a test case now:

Thanks to the nicely organized system of iteminfo_parts flags defined in src/iteminfo_query.h, these test cases are quite straightforward to write and expand upon (and I believe I've left plenty of room for expansion).

[wapcaplet]

There's a pretty decent chunk of tests in here now. I've leaned heavily on the Halligan bar, since it has a nice profile of useful attributes that I am guessing are likely to be stable, however a better way to write these tests would be to specifically set up the test items with desired attributes before trying to verify them in the formatted strings.

A still better way would be to load test items from JSON files in tests/data - but I see there's only one little file in there now, so I'm not sure how I'd approach that here.

[ifreund]

This is already looking great and will be really nice to have. Thanks for adding these.

[wapcaplet]

Build failures appear to be related to #37706

[wapcaplet]

I see one of these has failed on the magiclysm CI (since I didn't account for the enchanted tailor's kit in my repair options - a weakness of using in-game items for testing). Anyhow I am simply removing that test scenario for now so it doesn't block the merge.

[wapcaplet]

I see some Travis CI failures on the food freshness tests:

For fresh food:

• Expected: This food looks as fresh as it can be.
• Actual: This food looks as fresh as it can be. It still has about 6 weeks until it spoils.

For old food:

• Expected: It's on the brink of becoming inedible.
• Actual: It's just about 0 seconds from becoming inedible.

This part is (correctly) appearing for all food tests:

• This food is perishable, and at room temperature has an estimated nominal shelf life of 6 weeks

Guessing these are due to some recent changes in master. Looking into them now . . .

Looks like these are a side effect of possible skill-spill from other tests - I see now that more skilled characters are supposed to see the more detailed spoilage estimates, per:

Cataclysm-DDA/src/item.cpp

Lines 934 to 938 in ab75d68

	static std::string get_freshness_description( const item &food_item )
	{
	// So, skilled characters looking at food that is neither super-fresh nor about to rot
	// can guess its age as one of {quite fresh,midlife,past midlife,old soon}, and also
	// guess about how long until it spoils.

Should be fixed by forcing g->u.empty_skill() in commit c80a0b5

[ifreund]

Good catch, this looks ready for merge to me.