Testing Tripal Fields

[laceysanderson]

I'm working on automated testing for the sbo__relationship field (you can see progress here) and am considering whiting a helper class to make field testing easier. I think ideally it would be done very generically and contributed back to Tripal Test Suite to make testing fields easier for everyone :-)

Questions/Discussion:

• Is there any reason not to take this approach? My method is in it's infancy so that may be a reason but it works which is better then what we have.
• Is a general class a good approach?
• Should I inherit from anything existing in TripalTestSuite?
• Where would such a file go?

I'm currently very uncertain how to contribute back to TripalTestSuite so advice/guidance would be Very Appreciated! For now, I will continue on in my branch with the generic class approach just to keep development of the sbo__relationship widget going but I am very happy to change it based on discussion here :-)

[bradfordcondon]

so you're talking about initializeWidgetClass?? It looks like you're on the right track to me. I'd have to try it out to figure out what else it needs to be generic.

I would think it should take as input an entity/bundle to attach to and the field component itself?

I would think the right approach is either to a) define a test class that is a fieldTestClass that extends TripalTestCase or b) provide a class that can be used within TripalTestCase to handle the entity and field creation. I prefer b.

said class could live in https://github.com/tripal/TripalTestSuite/tree/master/src . you would also need to provide a mock I think?

edit goes without saying but we'd be very happy to include this, i think its great, thank you.

[laceysanderson]

I was also leaning towards B. I've started it as TripalFieldTestHelper 🤷‍♀️ In addition to initializing the Field/Widget/Formatter, in the _contructor(), my intent was to provide

• static methods to grab the field/instance info: this is very helpful if you want to set the field or instance settings for your test

Additionally, it would be nice to provide an easily method to fake form_state, items, element, widget (as passed to the form), etc. Would it be best to provide each as a Mock or a Helper function? I get the feeling Mock is for classes whereas these are more stand-alone? or perhaps I include them as methods in the helper class?

[almasaeed2010]

Hello all!

I can see this being implemented as a Concern in terms of TripalTestSuite. A concern would be a trait that can be used in a test class. It would provide the methods it needs to make assertions about fields and would make it possible to opt in or out of using the methods easily. This is the structure I've been using to create an easy way to make object specific assertions. You can see an example in the MakesHTTPRequests concern which provides a set of methods that are accessible directly in the test class but the returned object is a TestResponse. The TestResponse in turn would provide a set of assertions to make sure it contains the data you expect.

I think it should be the same way for fields. Of course since the Service is a separate class, we can always use a Helper function instead of Concerns too if you prefer.

I hope this helps a little :) I can't wait to see field testing available!

Thanks!

[laceysanderson]

Hmmmm... interesting! This is my class so far and here are the associated tests. Also, here is how I use it.

I can see this being implemented as a Concern in terms of TripalTestSuite. A concern would be a trait that can be used in a test class. It would provide the methods it needs to make assertions about fields and would make it possible to opt in or out of using the methods easily.

This sounds perfect!

So in terms of methods, can I still have my constructor? I notice it's missing in MakesHTTPRequests...

returned object is a TestResponse.

This I will need to wrap my head around a little more... How do I return the initialized widget class? or do I instead include a testMethod method which takes an array of arguments to be passed to the method (e.g. testMethod('validate', [$arg1, $arg2, $arg3])which then callsField->validate($arg1, $arg2, $arg3)` and returns the result?

[bradfordcondon]

@almasaeed2010 is there info on what a concern is i can read?

[almasaeed2010]

Here is an example using the class you provided:

We'd create a Trait called ProvidesFieldTests with the following content:

use FULL_NAME_SPACE\TripalFieldTestHelper;

trait ProvidesFieldTests {
  public function prepareField($bundle_name, $machine_names, $entity, $field_info, $instance_info) {
    return new TripalFieldTestHelper($bundle_name, $machine_names, $entity, $field_info, $instance_info);
  }
}

Then add the trait to the main TripalTestCase by "using" it just like we use MakesHTTPRequests.

Does that make it any clearer? We can always hop on a call if easier 😄

[almasaeed2010]

@bradfordcondon I honestly can't find anything online about it but in general concerns would be anything the test class can provide to help the user test a service the framework provides ie publishing entities, testing fields, ... etc

[bradfordcondon]

so to rephrase to be sure i understand, concerns are add-on utuilities for the test class?

[almasaeed2010]

Yes that's right