I've worked in all aspects of code from libraries, DB design, Web/API-services, requirements and everything else, but I've happily fallen into being very strong in the design of User Interfaces. It's not that I'm artsy (I'm not) but I have a knack of being able to architect UI code so that the artsy presentation skin can be added easily without effecting the functionally of the UI.
Unlike other layers of an application / service (or whatever layer), there are discreet operations and parameters with expected results. Code can be written and tests created to the expected behavior. It's the same with DB operations but will a bit more complexity based on relationships, triggers and transactions.
Not so easy with UI code.
Write code to show a form, easy. Add validation and error handling and it gets a bit busier. Add related actions, operations, state tracking for enabling / visibility, mix with async operations for data streams and any gee-wiz widget behavior and it can get overwhelming. If these behaviors could be coded independently and then coupled together for final implementation that would be great, but they can't. They are interrelated in their behavior and operation.
This is why writing Unit tests for U.I. code generally does not exist. The logic required for unit tests would modify the code (thus changing it's behavior), not handle the related states and behaviors so that what ends up being tested are the tests and not the U.I. The side effect is to make the U.I. even more complex to update, modify and maintain. Not a good place to be.
With some good behavioral and design patterns this can all be mitigated. The working with multiple "behavior" balls in the air and making sure that the design patterns I have in place cover the U.I. needs.
This is what I find fun and challenging.
Not so easy with UI code.
Write code to show a form, easy. Add validation and error handling and it gets a bit busier. Add related actions, operations, state tracking for enabling / visibility, mix with async operations for data streams and any gee-wiz widget behavior and it can get overwhelming. If these behaviors could be coded independently and then coupled together for final implementation that would be great, but they can't. They are interrelated in their behavior and operation.
This is why writing Unit tests for U.I. code generally does not exist. The logic required for unit tests would modify the code (thus changing it's behavior), not handle the related states and behaviors so that what ends up being tested are the tests and not the U.I. The side effect is to make the U.I. even more complex to update, modify and maintain. Not a good place to be.
With some good behavioral and design patterns this can all be mitigated. The working with multiple "behavior" balls in the air and making sure that the design patterns I have in place cover the U.I. needs.
This is what I find fun and challenging.
Comments
Post a Comment