You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Unit tests should test interface and only interface #35
The unit tests packaged with ESAPI should only test the interface and not
contain code that is specific to the default implementations. This means
two things in particular:
All types should be from the API interfaces
Methods called on instances being tested should only reflect those in
the API
Maybe split the tests in two. One folder for interface and one for default
implementations. That way you can still test the default implementations on a finer
granularity.
The original Google Code issue seems to imply that the reference implementation classes should not be tested at all, which is of course absurd. One cannot write meaningful unit tests in the absence of any implementation at all.
That said, if the objection is against testing implementation specific methods in a JUnit test meant to test interfaces, that I can agree with. As noted, the AuthenticatorTest class, which presumably is meant for testing the implementation of only the methods defined in the Authenticator interface, also includes a 'testSaveUsers()' test case that tests the implementation of FileBasedAuthenticator.saveUsers() method, a method which is not defined in the Authenticator interface. Clearly that 'testSaveUsers()' method should be moved to a implementation specific class, such as FileBasedAuthenticatorTests (which does not currently exist).
At this point, I do not think it is prudent to make these changes before the anticipated ESAPI 3.0 release, and for that reason, I have changed this to the 3.0 milestone.
Activity
meg23 commentedon Nov 13, 2014
From eofte...@gmail.com on September 09, 2009 23:54:21
Maybe split the tests in two. One folder for interface and one for default
implementations. That way you can still test the default implementations on a finer
granularity.
meg23 commentedon Nov 13, 2014
From manico.james@gmail.com on October 31, 2010 22:57:37
Status: Accepted
Owner: jeff.wil...@owasp.org
Labels: Milestone-Release2.1
meg23 commentedon Nov 13, 2014
From chrisisbeef on November 20, 2010 13:14:10
Blockedon: 168
meg23 commentedon Nov 13, 2014
From chrisisbeef on November 20, 2010 13:14:34
Blockedon: -168 186
meg23 commentedon Nov 13, 2014
From chrisisbeef on November 20, 2010 13:14:55
Owner: chrisisbeef
meg23 commentedon Nov 13, 2014
From chrisisbeef on November 20, 2010 13:15:28
Labels: Component-Other Build-Maven
kwwall commentedon Feb 1, 2016
Previous comment had blocked on Google Code issue 186. That is now issue #196.
kwwall commentedon Jul 5, 2019
The original Google Code issue seems to imply that the reference implementation classes should not be tested at all, which is of course absurd. One cannot write meaningful unit tests in the absence of any implementation at all.
That said, if the objection is against testing implementation specific methods in a JUnit test meant to test interfaces, that I can agree with. As noted, the AuthenticatorTest class, which presumably is meant for testing the implementation of only the methods defined in the Authenticator interface, also includes a 'testSaveUsers()' test case that tests the implementation of FileBasedAuthenticator.saveUsers() method, a method which is not defined in the Authenticator interface. Clearly that 'testSaveUsers()' method should be moved to a implementation specific class, such as FileBasedAuthenticatorTests (which does not currently exist).
At this point, I do not think it is prudent to make these changes before the anticipated ESAPI 3.0 release, and for that reason, I have changed this to the 3.0 milestone.