Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Remove deprecated description field from Sections #1319

Closed
philsquared opened this issue Jun 26, 2018 · 4 comments
Closed

Remove deprecated description field from Sections #1319

philsquared opened this issue Jun 26, 2018 · 4 comments
Milestone

Comments

@philsquared
Copy link
Collaborator

Description

Like with TEST_CASE, SECTON started out with a separate description field as the name field was intended to be a hierarchical scheme, and the description the more wordy version.
When we dropped the hierarchical naming and the name became the wordy field description fell redundant. For TEST_CASE the position is now taken by tags (although it still supports description, too, for now). For SECTION it is just dead weight.

I've removed any usage of the field internally, and in the test and example code. But the macro argument and member variable of SectionInfo are part of the public interface and need to remain for now. They should be considered deprecated.

In v3 we will remove the macro argument and SectionInfo field altogether.

I'll consider adding a deprecation warning in v2 if the field is used.

@philsquared philsquared added this to the 3.0 milestone Jun 26, 2018
@capsocrates
Copy link

Bummer, I just started using short, descriptive SECTION names to make it easier to run a specific section. So I've been moving descriptive text for the SECTION into that field.

For example, here's some of my test code (with most of the actual code ripped out to focus on the use of SECTIONs

TEST_CASE("Server")
{
	const auto uri{
		web::http::uri_builder{}
		.set_scheme(U("http"))
		.set_host(U("localhost"))
		.set_port(34568)
		.to_uri()
	};
	SECTION("Construction", "It can be constructed from a valid URI without exceptions")
	{
		REQUIRE_NOTHROW(Web::FileServer{ uri });
	}
	SECTION("FileRegistry", "Files can be registered with it")
	{
		//test code for adding files to the server goes here
		SECTION("FileDeregistry", "Files can be un-registered from it")
		{
			//test code for removing files from the server goes here
			REQUIRE(server.FilesBeingServed().empty());
		}
	}
	SECTION("InvalidFileRegistry", "Files cannot be registered with it twice")
	{
		//test code goes here
		SECTION("InvalidFileDeregistry", "Files that have not been registered fail to unregister")
		{
			REQUIRE(!server.StopServingFile("cde"));
		}
	}
	SECTION("Download", "Files can be downloaded from the server")
	{
		//test code goes here

		SECTION("DownloadOne", "It can download one file from the server")
		{
			//test code goes here
		}

		SECTION("DownloadTwoAsync", "It can download two different files asynchronously")
		{
			//test code goes here
		}

		SECTION("DownloadTwoParallel", "It can download two different files and read them in parallel")
		{
			//test code goes here
		}

		SECTION("NonexistentFile", "Requesting a file that the server does not have results in an error")
		{
			//test code goes here
		}
	}
}

This lets me do something like WebTest Server -c Download -c DownloadTwoParallel to run just one specific section (and its parents). If the name field is also the description field, typing out those arguments becomes more difficult and error-prone.

@capsocrates
Copy link

Any word on how we'll be able to get the above functionality when descriptions are removed?

@horenmar
Copy link
Member

@capsocrates That is an interesting use case. Would you be ok with the SECTION macro being able to take two arguments, but just ignoring the second one?

@capsocrates
Copy link

capsocrates commented Oct 31, 2019 via email

horenmar added a commit that referenced this issue Nov 3, 2019
Users can still write a description for their sections, but it will
no longer be saved as part of the `SectionInfo` struct. This ability
has also been added to the documentation.

Closes #1319
@horenmar horenmar removed the Revisit label Oct 16, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants