Open nbarbettini opened 8 years ago
My current thought is that we can look for the environment variable STORMPATH_APPLICATION_HREF
and then write a function that can delete an account given an email address. That does make the tests dependent on that environment variable, though.
Anyone else have a better idea? (Or disagree with my premise?)
Sorry, I'm not understanding why we shouldn't grabit from cookies?
/register
doesn't set any cookies, unless web.register.autoLogin = true
, which is not the default.
Right. Oh well, I would say cleanup is low priority anyways, since we're using GUIDs?
Fairly low prio, just "annoying".
I think this does affect the RegisterIT maybe I'm wrong, but since we use a single testAccount I have a couple of test failing due to email conflict
That's odd @jarias. It should be generating a new random GUID for those email addresses. See here: https://github.com/stormpath/stormpath-framework-tck/blob/master/src/test/groovy/com/stormpath/tck/util/TestAccount.groovy#L10
I don't think we're reusing the same testAccount instance multiple times - if we are, it should be fixed.
@nbarbettini That's the case actually reusing the same instance, got it fix just need to PR it, probably tomorrow morning.
It's easy to clean up accounts that are registered through JSON - we just grab the account href from the
sub
claim and schedule it for cleanup. (see https://github.com/stormpath/stormpath-framework-tck/blob/master/src/test/groovy/com/stormpath/tck/AbstractIT.groovy#L96)It's trickier to delete accounts that are registered through a form. The original demo IT used 2 tests (register and login) to eventually get the href from the login cookies. (see https://github.com/stormpath/stormpath-framework-tck/blob/master/src/test/groovy/com/stormpath/tck/login/LoginOldIT.groovy#L147)
I think the tests should be split up, though. This means we'd need some way of deleting a created account without knowing the href.