The company I work for primarily produces RESTful APIs, written in Java. The current e2e tests are written in Python. There’s some momentum building to shift the e2e to Java, which I’m okay with, but I wonder how people avoid the tests becoming tautologies?
Developer fluency and no need to context switch from Java to Python are the main reasons to switch to Java. One of the other reasons folks have mentioned is that they can leverage the existing objects in their test code.
I’m not a huge fan of this, especially for the request and response objects, as if a test is written using the objects from source, it’s easy to have happy path tests always pass, even if someone breaks a contract (i.e. changing a property to be required as opposed to optional). It also seems like you’d need custom objects to test invalid requests (i.e. the constructors for the request object wouldn’t let you have invalid data types, empty fields, etc)?
The ideas I’ve come up with so far:
- be diligent in code reviews and make sure such tests cases are explicitly enumerated?
- do not use the POJO from source, but instead parse the request and response objects as strings (instead of JSON). I lean towards this, but makes it a little hard to set/read object properties, and could become a string parsing/regex nightmare.
- Have custom POJOs for tests - These would have to be fully independent and not extending the existing objects. Biggest challenge were would be to enforce not copy/pasting code from the src object to the test object, and keeping the test objects essentially as clean-room implementations
What options/strategies am I missing?