Consider splitting up layer_validation_tests.cpp?

[Tobski]

Whilst I was working on validation for VK_KHR_create_renderpass2 (#357), I noticed a LOT of issues manipulating and working with this file, not limited to:

• Slow to syntax highlight/format/autocomplete
• Default git client settings won't diff anything that large
• Diffs that are generated for a file that large are super unwieldy to review
• Difficult to find things within it

Would it make sense to split this file up into multiple, grouped by functionality? For instance, as part of #357 I ended up grouping all of the render pass VUID tests together so that I could figure out more easily what was/wasn't being tested, and keep my edits local rather than jumping over the entire file. So an easy one to split out into a separate file would be "anything that tests renderpass VUs".

I'd be more inclined to write decent tests in future if the testing files weren't quite so unwieldy, so I think it'd be a useful change?

[chrisforbes]

👍

[mikew-lunarg]

+1

[jzulauf-lunarg]

Triage notes: as a first step, the test state and utility functions declared and implemented in layer_validation_tests.cpp need to be extracted and properly broken down into .h and .cpp components. An easy second step could be splitting the VkPositiveLayerTest (93 tests) tests from the negative tests, and potentially extracting a few of the common prefix non-positive tests (349) `into files name with the common prefix used.

The most common prefixes (for non-positive tests) are:

6         CreateComp
7         SecondaryC
7         TwoQueueSu
8         Framebuffe
9         Descriptor
9         InvalidCmd
11        CreateImag
32        RenderPass
55        CreatePipe

Isolating a 100 tests would require four prefixed files.

Further size reduction would involve adding (and potentially renaming) tests that are logically associated with the selected prefixes (or other common potentially prefixes) to further reduce the size of the generic test file.

Any test renaming should be discussed with @cnorthrop ahead of time as he maintains a name based blacklists for known failures in a test system he manages.

One other possibility to reduce size is to find additional test code patterns that can be factored into common utility functions, structs, and classes.

[JasperNV]

I plan on tackling this as well after #848 is merged.

[locke-lunarg]

@JasperNV I'm working on this issue. If you have done anything for that, could we discuss it? I'm really appreciated.

[locke-lunarg]

PR #924 , PR #949 , PR #976

The three PRs are for this issue. If you have any idea to make it better, please let me know.