Personally, I wouldn't want to make myself dependent from some proxies that are out
of my control. The Internet is not a very reproducible test environment for this sort of tests. So the question is: At which level do you want to (or: can you) control your test environment, e.g. application-level or network-level?
I assume, that you already have at least control over the test generators and the application?
Several approaches are conceivable, depending on the degree of influence
that you have upon your test environment (HW+SW, SW only) - and budget:
- HW1: use a test-PC and configure it's network card with the IPs you want to test / arrange proper routing
- HW2: configure a NAT-capable (network address translation) device in your network (e.g. a load balancer), mapping your current test-PCs IP to the ones desired / if I remember correct, there are NAT devices available that can map a source IP+port to a destination IP+port, so your test client can control the IP address by selecting a destination port
- SW1: enhance your application to accept an additional (CGI?) attribute, e.g. (__TESTIP=12.34.56.78) that overrides the current IP address value
/ you might want to disable this feature in a production environment / risk to introduce new errors
- SW2:
Don't know it this really works: Setup some virtual machines with their individual IPs using the same physical NIC (e.g. Solaris Zones)
HW1+2 have the advantage not to influence your SUT. However, HW1 requires access to the test clients hardware and HW2 is costly in terms of hardware itself and configuration overhead. SW1 should be the cheapest solution but comes with the price of modifying the software under test (SUT). On the other hand, SW1 would allow you to simulate all conceivable IPs (countries) with your client ... a nice set-up if you have to do regression-tests often. Personally, I would vote for SW1.
For what its worth, many browsers allow to define a preferred language, e.g. my browsers sends an Accept-Language: de,en;q=0.9 with each request... maybe it gives you further clues to present your localised content? IF you want to decide what language to use for display, then I would even consider country detection based on the IP as a fallback when no language preference was given by the client.