On 26 May 2011 15:03, Stephen Connolly <[email protected]> wrote: > On 26 May 2011 12:57, sebb <[email protected]> wrote: > >> On 25 May 2011 10:04, Stephen Connolly <[email protected]> >> wrote: >> > These were Nicolas' tests, but a good catch and I've made the change. >> > >> > BTW, the aim here is to reproduce the bugs for the first go... so if >> > Plexus Utils is incorrectly using platform encoding then actually the >> > test would be correct! So it may be that we revert this... should >> > probably add an annotation around tests which are testing bugs >> >> Relying on the platform encoding in test cases to expose bugs is >> surely just as error prone as relying on the platform encoding in the >> code under test? >> > > How do you test that the code under test is using the platform encoding?
I would try and set the default encoding to a special value that is bound to cause problems. I don't know how difficult it is to create a new encoding, but in theory one could create an encoding that always threw a run-time error if used. > There are some bits of code in Plexus Utils that is using the platform > encoding, this could be considered a bug, but it is a bug that we have to > reproduce, so if your tests send platform encoding in and get platform > encoding out -> we know it is using platform encoding (or it's using the > same encoding as platform encoding as a default) Not necessarily - in the case in point, the use of default encoding in the test code does not help show whether or not the target code is using platform encoding. > The only way I can consider of testing this reliably is to keep the test > code using platform encoding and have two executions of surefire, the first > leaving things as is and the second with file.encoding set to a different > value. > > Unfortunately, the file.encoding system property is only read at start-up, > so two executions is the only way to be sure. > > >> The failures will at best only occur on certain platforms, and may >> never occur if the test code makes the same assumptions as the code >> under test. >> >> In order to test code that might rely on the platform encoding, surely >> the only safe way to do this is to set the default to various >> different encodings, including ones that are known to cause problems - >> e.g. Turkish and Ebcdic. >> >> > On 25 May 2011 09:48, Hervé BOUTEMY <[email protected]> wrote: >> >> notice that encoding (US-ASCII or UTF-8) should be precised both when >> >> converting String to byte[] and byte[] to String, or you're implicitely >> using >> >> platform encoding which is not the best: if anybody tries to run tests >> on an >> >> EBCDIC platform, they will fail (I know, this is quite rare, but that's >> >> chicken and egg problem: it is rare because it always fail for stupid >> reasons, >> >> then nobody takes care of such little things) >> >> >> >> Regards, >> >> >> >> Hervé >> >> >> >> Le mercredi 25 mai 2011, [email protected] a écrit : >> >>> + assertThat( new String( new Base64().encode( "test".getBytes() >> ) >> >>> ), is( "dGVzdA==" ) ); } >> >> >> >> --------------------------------------------------------------------- >> >> To unsubscribe, e-mail: [email protected] >> >> For additional commands, e-mail: [email protected] >> >> >> >> >> > >> > --------------------------------------------------------------------- >> > To unsubscribe, e-mail: [email protected] >> > For additional commands, e-mail: [email protected] >> > >> > >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> >> > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
