# Question regarding test system

- Thread: https://externals.io/message/19426
- Original archive: https://news-web.php.net/php.internals/19426
- Started by Marcus Boerger on 2005-10-05T23:14:45+00:00
- Messages: 4
- Reply by email to internals@lists.php.net
- More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt

---

## #19426 — Marcus Boerger — 2005-10-05T23:14:45+00:00

URL: https://externals.io/message/19426#19426

Hello guys,

  i had a chat with Dmitry this morning regarding the unpleasant state of
our test system. I assume here that everyone agrees that it is quite
difficult to provide each and every test expectations in two variants, one
for native string executoin (e.g. unicode_semantics=off) and one for unicode
execution (e.g. unicode_semantics=on). The easy way out is to have var_dump
not print 'unicode' for namely values but instead use 'string' always. Since
the encoding is meant to be transparent anyway there shouldn't be a problem.
And in case we have tests where the difference is important we can overwrite
the setting in the --INI-- setting and use the --UEXPECT-- as we are doing
now. Dmitry now came up with the idea of providing a new ini setting to
control this behavior. He suggests to name it "var_dump.show_unicode=on/off"
Any comments?
  

Best regards,
 Marcus

---

## #19447 — Sebastian Nohn — 2005-10-06T16:34:43+00:00

URL: https://externals.io/message/19426#19447 · In reply to: #19426

Marcus Boerger wrote:

> execution (e.g. unicode_semantics=on). The easy way out is to have var_dump
> not print 'unicode' for namely values but instead use 'string' always. Since
> the encoding is meant to be transparent anyway there shouldn't be a problem.
> And in case we have tests where the difference is important we can overwrite
> the setting in the --INI-- setting and use the --UEXPECT-- as we are doing
> now. Dmitry now came up with the idea of providing a new ini setting to
> control this behavior. He suggests to name it "var_dump.show_unicode=on/off"
> Any comments?

Sounds like a good idea. BTW: I'm missing 5.0.5 and 5.1(0RC*|-DEV) QA-Spam.

Sebastian

---

## #19445 — Andrei Zmievski — 2005-10-06T17:21:31+00:00

URL: https://externals.io/message/19426#19445 · In reply to: #19426

It has nothing to do with the encoding. `var_dump()` outputs the value 
type, which is 'string' for native strings and 'unicode' for Unicode 
strings. I don't see why we should merge the two.

-Andrei



> Hello guys,
>
>   i had a chat with Dmitry this morning regarding the unpleasant state 
> of
> our test system. I assume here that everyone agrees that it is quite
> difficult to provide each and every test expectations in two variants, 
> one
> for native string executoin (e.g. unicode_semantics=off) and one for 
> unicode
> execution (e.g. unicode_semantics=on). The easy way out is to have 
> var_dump
> not print 'unicode' for namely values but instead use 'string' always. 
> Since
> the encoding is meant to be transparent anyway there shouldn't be a 
> problem.
> And in case we have tests where the difference is important we can 
> overwrite
> the setting in the --INI-- setting and use the --UEXPECT-- as we are 
> doing
> now. Dmitry now came up with the idea of providing a new ini setting to
> control this behavior. He suggests to name it 
> "var_dump.show_unicode=on/off"
> Any comments?
>
>
> Best regards,
>  Marcus

---

## #19450 — Marcus Boerger — 2005-10-06T18:07:58+00:00

URL: https://externals.io/message/19426#19450 · In reply to: #19445

Hello Andrei,

  transparent == doesn't really matter. And if you insist, will you write
all the tests and maintain them?

marcus

Thursday, October 6, 2005, 7:21:31 PM, you wrote:

> It has nothing to do with the encoding. `var_dump()` outputs the value 
> type, which is 'string' for native strings and 'unicode' for Unicode 
> strings. I don't see why we should merge the two.

> -Andrei

> 

> > […]




Best regards,
 Marcus