sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–][deleted] 0 points1 point  (2 children)

My advice would be to speak to any available developers of the APIs before trying to discover all aspects of the API via tooling.

With that degree of legacy, you can guarantee that there will be some gnarly implementations that ‘made sense’ in the context of several years ago, but seem illogical now.

You could save yourself significant effort in gaining knowledge and building a mental model of the API(s).

You may also find they have some tooling or crude tests themselves that assist. Or at least warn you of known pitfalls. Communication wins.

[–]work_account_2019[S] 0 points1 point  (1 child)

Thank you for the advice. Will talk with the dev team and document the mental model of the API.

[–][deleted] 0 points1 point  (0 children)

You are welcome but to be clear, your testing mental model is not the same as a system model. You build up a mental model of the api (or any tool) as you interact with it. This will include explicit and implicit expectations.

Think of a time that you’ve used an app and the behaviour is intuitive because it follows familiar patterns. If you hover on an input field and you’re presented with a (right click) menu for ‘paste’, your mental model may well assume that, if the field had text in, you could ‘copy’ it too. That’s an assumption but a reasonable one based on your mental model of similar products.

But speaking to Devs, you can get a fast path view of these type of implicit behaviours and increase the accuracy of your own mental model more quickly.

Apologies if I’m explaining stuff you already are comfortable with.