Skip to main content
Mod Moved Comments To Chat
added 193 characters in body
Source Link
Eric
  • 54.4k
  • 11
  • 104
  • 196

An alternate approach is to just not annotate it and test it via the methods that use it.

It's private for a reason so why open it up to test methods.

You can create scenarios to test you logic for the methods that call it.

Use TestVisible sparingly and if that cannot be done question why it is private.

In your case just call verifyDate with different dates and assert the returned values are correct. Use different combinations to test the varying outcomes. Also test null dates to ensure error handling/protection is appropriate

Sometimes you have to use TestVisible like for a property that you need to set to alter behavior outside of the normal code flow. But if it can be tested within the normal code flow I would go that route first

Private methods can only be access from within the class they are defined. As such only the methods within that class use them. Test these methods is organic as you test the rest of the class

An alternate approach is to just not annotate it and test it via the methods that use it.

It's private for a reason so why open it up to test methods.

You can create scenarios to test you logic for the methods that call it.

Use TestVisible sparingly and if that cannot be done question why it is private.

In your case just call verifyDate with different dates and assert the returned values are correct. Use different combinations to test the varying outcomes. Also test null dates to ensure error handling/protection is appropriate

Sometimes you have to use TestVisible like for a property that you need to set to alter behavior outside of the normal code flow. But if it can be tested within the normal code flow I would go that route first

An alternate approach is to just not annotate it and test it via the methods that use it.

It's private for a reason so why open it up to test methods.

You can create scenarios to test you logic for the methods that call it.

Use TestVisible sparingly and if that cannot be done question why it is private.

In your case just call verifyDate with different dates and assert the returned values are correct. Use different combinations to test the varying outcomes. Also test null dates to ensure error handling/protection is appropriate

Sometimes you have to use TestVisible like for a property that you need to set to alter behavior outside of the normal code flow. But if it can be tested within the normal code flow I would go that route first

Private methods can only be access from within the class they are defined. As such only the methods within that class use them. Test these methods is organic as you test the rest of the class

added 211 characters in body
Source Link
Eric
  • 54.4k
  • 11
  • 104
  • 196

An alternate approach is to just not annotate it and test it via the methods that use it.

It's private for a reason so why open it up to test methods.

You can create scenarios to test you logic for the methods that call it.

Use TestVisible sparingly and if that cannot be done question why it is private.

In your case just call verifyDate with different dates and assert the returned values are correct. Use different combinations to test the varying outcomes. Also test null dates to ensure error handling/protection is appropriate

Sometimes you have to use TestVisible like for a property that you need to set to alter behavior outside of the normal code flow. But if it can be tested within the normal code flow I would go that route first

An alternate approach is to just not annotate it and test it via the methods that use it.

It's private for a reason so why open it up to test methods.

You can create scenarios to test you logic for the methods that call it.

Use TestVisible sparingly and if that cannot be done question why it is private.

In your case just call verifyDate with different dates and assert the returned values are correct. Use different combinations to test the varying outcomes. Also test null dates to ensure error handling/protection is appropriate

An alternate approach is to just not annotate it and test it via the methods that use it.

It's private for a reason so why open it up to test methods.

You can create scenarios to test you logic for the methods that call it.

Use TestVisible sparingly and if that cannot be done question why it is private.

In your case just call verifyDate with different dates and assert the returned values are correct. Use different combinations to test the varying outcomes. Also test null dates to ensure error handling/protection is appropriate

Sometimes you have to use TestVisible like for a property that you need to set to alter behavior outside of the normal code flow. But if it can be tested within the normal code flow I would go that route first

Source Link
Eric
  • 54.4k
  • 11
  • 104
  • 196

An alternate approach is to just not annotate it and test it via the methods that use it.

It's private for a reason so why open it up to test methods.

You can create scenarios to test you logic for the methods that call it.

Use TestVisible sparingly and if that cannot be done question why it is private.

In your case just call verifyDate with different dates and assert the returned values are correct. Use different combinations to test the varying outcomes. Also test null dates to ensure error handling/protection is appropriate