The title is not strictly true, in that I had a new Page Object to handle a public domain web-based calculator. Doing this emphasised that in changing technologies to achieve the same functionality, the design may change… and actually affect the behaviour of the test. In this case, in the Window Forms version, I had a dedicated read-only box for the answer, but in the public html version (one I just picked from the internet, not one I wrote), one box services the entry of the first number, the second number, and the presentation of the answer. That means a) the Page Object contract changes, meaning that b) its Test client has to change. Well, to be more precise the HTML Page Object differs from the Forms Page Object in behaviour, although it implements the same functionality. In fact using this web based calculator actually shows a defect in the functionality, I suggest: in my tests, I have 24 and 37 as the two input integers with 61 as the answer. That’s fine for the Forms test, but for the Web test, the actual answer is [space][space]61[dot]. So the Test is doing its job in that it is unaware of what technology is at play, and the Page Object is doing its job in abstracting away the technology.
For now, this is the Test, where I have edited the existing test for the new behaviour (I suggest that at any one time you would not have 2 versions of the test, you would switch over one day e.g. from Forms to HTML, so that approach is valid). However, it does bring into relief the poor naming of the Test class, i.e. WindowsFormsControlsTest: whatever it is, it should not mention the technology, as it is not aware of it. Well, maybe… at some point you have to give the SUT the context. Anyway the test…
And the Page Object between the code and the test:
Code for the test.
Code for the page object.