Basically the idea is that what is more valuable to app/framework developers, is NOT another API that they have to bake into their product, BUT a set of Unit/Integration tests that they can use to validate what they are doing.
In this world ESAPI would be an example of what that could look like, BUT what would be the expectation is that app and framework developers implement the same 'behaviour/capability' into their code.
And then ESTAPI would be used to develop AND validate those capabilities.
Let's take a simple example: HtmlAttributeEncoding and JavascriptEncoding across the multiple ESAPI language implementation? (Java, .NET,PHP, etc...) Shouldn't ALL of them pass the same ESTAPI test? surely ALL should have the same behaviour right? (i.e. given the same input, provide the same output)
Same thing for the popular Java Frameworks (Spring, Struts, Tapestry, JSF, etc...). We should be using ESTAPI to measure (and understand) how those frameworks behave.
Of course that there are cases where the devs will chose to use the ESAPI.jar (& its dependencies), BUT my view for a while now, is that 'THAT esapi.jar' adoption should NOT be the first step in ESAPI usage. This 'adaption' COULD be one of the options later down the line, but the first step should be on a bunch of ESTAPI tests adapted to the targeted app.
What I also like about the ESTAPI idea, is that it will give drive (and push) the ESAPI team to really segment and separate the esapi.jar dependencies. Since it will be much easier (or practical) to write ESTAPI tests on single-focused JARs, with its dependencies injected (i.e. using DI)
