Angie Jones has come out to talk to us about "Code Smells", where we have code that "works", but may have some unusual issues that don't necessarily jump out at us.
More than just talk about the issue, Angie is actually walking us through and showing a real project that has some definite issues. The first example she uses is classes that are too long, where there is a lot of stuff put into a single class and it doesn't have a specific purpose. Oftentimes classes grow over time because there's no other logical place to put something. Think of writing a test where you put a lot of browser interaction into a class so that it's readily available. One one hand, it makes sense, but on the other hand, if it is overloaded or the items added to a class can be grouped somewhere else, take the time to put it there.
Another common smell is "Duplicate Code", where if you have an issue where something is repeated in multiple places, you end up having to do what Angie calls "Shotgun Surgery" (I just love that term :) ). Anything being duplicated more than twice is probably a really good indication that a separate class with that information probably makes a lot of sense.
Angie calls out the "Indecent Exposure" smell. If you are showing too much of your data, you may allow for people to get to your data and information in ways you may not want to. This is fixed by narrowing the scope of your classes, making certain methods private when they should be and only keeping public methods that actually need to be public that distinction.
Something that I'm all too familiar with is the issue of explicit waits. Yes, I do this. No, I'm not proud of this. Yes, I can do better. Angie encourages us to Wait Intelligently, by either polling for an element or to make sure that the test doesn't move forward until there's a confirmation that an item is present.
Frameworks are supposed to drive the logic of the browser and to create a state condition. Frameworks don't actually test anything, so putting assertion codes into the framework is a problem. Instead, we want to create state conditions that e can evaluate elsewhere. Otherwise, we may find ourselves painted in a corner unintentionally.
This was a really great discussion, and it was made the more effective by seeing the actual code being modified. I'm super happy to have had Angie come out to speak with us at BAST tonight and she has an open invitation to come out and talk any time she wants to :). For everyone else, thanks for indulging me this evening as I got to geek out a bit. 'Til next time!
