Set up project for PHPUnit testing

[danieliser]

• https://developer.wordpress.org/cli/commands/scaffold/plugin-tests/
• Ensure valid output for form tabs, sections/subtabs, fields, & json_encode output.
• Helper functions to ensure proper data integrity.

Resources from #731:

• https://make.wordpress.org/core/handbook/testing/automated-testing/
• WP Mock
• https://felix-arntz.me/blog/using-the-wordpress-test-suite/
• https://tfrommen.de/an-introduction-to-unit-testing-for-wordpress/
• http://wptest.io/
• https://www.smashingmagazine.com/2017/12/automated-testing-wordpress-plugins-phpunit/

[rgadon107]

@danieliser Three cheers. I'm so glad you've added this to your 'to-do' list. They'll take some time to write and implement. But they will vastly improve the quality of your code. I hope they will also reduce the number and complexity of support requests that you receive for PM.

[danieliser]

@rgadon107 - likely won’t help with support, but will catch edge case and potential data errors like the one last week.

I’ve been planning on it but had a hard time wrapping my head around what to actually test. Guess everything.

[rgadon107]

@danieliser

Guess everything.
LOL!

You might want to chat with @hellofromtonya at the WP Developer's Club/KnowTheCode.io about what you want to focus on in your testing. She's a big fan of that approach. Wrote a whole set of labs on the topic in the past 3 months. https://knowthecode.io/labs/unit-testing-brain-monkey

[fpcorso]

@danieliser Working on getting some of our initial testing set up now that we have all the linters set up. However, this is much larger than a single issue as we wouldn't get to 100% test coverage within 1 release. Additionally, you have links to both unit tests and integration tests resources which are also their own thing. Finally, we would also want to set up automated tests, through something like Travis CI.

So, for this initial issue, I am getting just the structure in place and a few basic unit tests created. From there, we can add to the unit tests. Perhaps we aim for creating a unit test for any part of the code we touch during each release. We'd eventually have acceptable test coverage over several releases then.

Then, I am going to create separate issues for integration tests and automated tests at the repo level.

[danieliser]

@fpcorso That makes since for most things, especially anything we are adding new.

That said it has always been brought to my attention that the way some of our current code base is written using static::methods() will not be testable.

So some code will need completely rewritten to be testable in those cases.

[fpcorso]

@danieliser You may have misunderstood because the static does not matter in this case as long as you can call the code. The bigger issue is that many of our methods and functions do a lot and would need to be broken into smaller, testable functions as we go.

For example, this simple test to make sure our pointers returns an array works correctly:

/**
	 * Tests to make sure data returned from `all_popups_main_tour` is valid.
	 */
	public function test_all_popups_pointers() {
		$pointers = PUM_Admin_Onboarding::all_popups_main_tour( array() );
		$this->assertTrue( is_array( $pointers ) );
	}

[danieliser]

@fpcorso Yea I mean more as a package, not the individual methods. There are some classes written in static form that I understood would be hard to properly mock. WP & we use global states/static instances instead of dependency injection which had some bearing on testability. Maybe I was misinformed.

[danieliser]

But for a quick set of wins, the Utils classes & methods could quickly be turned into tests. Knowning if the PUM_Utils_Array methods work as expected is crucial.