I want to ask you about your testcases hierarchy.
Dou you have one testcase per class or all testcases in one class?
I'm using python with selenium but I think it doesn't matter. All testcases are for the same website.
Hey.
You can put all test cases in one class, and when it grows (like 2KLOC :P ) then you really should re-factor it to separate classes.
Or you can put in into separate classes just to separate different groups of test cases.
So: 'It depends', 'whatever suits you', 'what your specific setup needs', 'the simplest thing that works', 'it is not that really important how you do it, as long as you do it', etc.. :)
Related
I've created several iterable classes. The code to provide these iterable properties is repetitive throughout each of the classes and clutters the code, distracting from the class unique functions.
I'm talking about having to write down __iter__, __next__, __getitem__,__setitem__, __len__, and append functions, the same way for each of my classes (see image below).
Is there any way to just write this down once, and import it in my class?
If this seems a too basic question, I promise I tried to work my way through the search results, but they landed me many different types of imports, function and class usage, without answering my question.
I learned the solution to this problem as I learnt more about inheritance:
So the solution would be inherit to start with:
class Samples(list):
...
I want to dispatch events to announce the progress of an asynchronous process. The event should contain 2 properties: work done and work total.
As the name suggests ;) i could use ProgressEvent; it has bytesLoaded and bytesTotal properties that i can use. However, my async process isn't loading bytes, its processing pixels, so the property names are a bit misleading for my use case - although the class name is perfect.
The alternative is to create a custom event with two properties that i can name how i like. But this means another class added to the code base.
So my question is; Is it better to reuse an existing class where the properties are suitable but maybe the naming isn't ideal; Or to create a custom class that perfectly fits the requirement? Obviously, one extra class is no big deal, but OOP is all about reusing stuff so adding an unnecessary class does make me uneasy.
I await your thoughts...
PS: This is my first question on stack so be gentle
For clarity, I'd create a new class. Adding a new class is not much overhead at all, especially for something simple like an event. I find that code is more readable when I don't have to make mental translations (like bytesLoaded really means pixelsLoaded). To me this is akin to choosing poor names for variables.
In addition, by going the other route and re-using the ProgressEvent class, I would feel compelled to document the code to indicate that we're dealing with pixels rather than bytes. That starts to get messy if you have a lot of classes that uses the event.
Re-use is great, but I'd opt for clarity as long as it doesn't impact your productivity or the app's performance.
writing in doc clearly, using custom event or ProgressEvent is well.
It's good to split code up into functions and classes for modularity / decoupling, but if you do it too much, you get really fragmented code which is also not good.
What is the golden rule for when to split code up into functions?
It really does depend on the size and scope of your project.
I tend to split things into functions every time there is something repeated, and that repetition generalized/abstracted, following the golden rule of DRY (Do not repeat yourself).
As far as splitting up classes, I tend to follow the Object Oriented Programming mantra of isolating what is the same from what is different, and split up classes if one class is implementing more an one large theoretical "idea" or entity.
But honestly if your code is too fragmented and opaque, you should try considering refactoring into a different approach/paradigm.
If I can give it a good name (better than the code it replaces), it becomes a function
I think you generally have to think of a chunk of codes have a chance of being reuse. It comes with experience to figure that out and plan ahead.
I agree with the answers that concentrate on reusability and eliminating repetition, but I also believe that readability is at least as important. So in addition to repetition, I would look for pieces of code (classes, functions, blocks, etc.) that do more than one thing.
If the name associated with the code does not describe what it does, then that is a good time to refactor that code into units which each have a single responsibility and a descriptive name. This separation of concerns will help both reusability, and readability.
Useful code can stick around for a long time, so it is important that you (or ideally someone else) can go back and easily understand code that was written months or years before.
Probably my own personal rule is if it is more than 2 lines long, and is referenced more than once on the same page (ASP.net), or a few times spread over a couple of pages, than I will write a function to do it.
I was taught that anything you do more than once should be a function. Anything similar should have a parent class, and above all else consult your source code "standards" within your organization. The latter mostly deals with formatting.
First, write the feature you're adding. (Notice the word "First", we tend to write a function/class before writing the feature, which might lead to having too many fragmentation).
Then, review the code you just wrote/changed, find what blocks of the code that is:
3-lines or more, and..
repeated, and..
Can be grouped under a named function. Because code is written by us, people (not programs), to be read/changed later by us, people (not programs).
Personally, I've never liked the MyObject naming of classes. I would guess that the status quo would agree but I'd like to see the other side of the argument and if there's any validity to it.
'My' is already used by me, use something else
I've never seen it done in production code, although I dare say it exists.
It's like the metasyntactic variables "foo" and "bar" - it's usually used as a placeholder for a real name.
So for example, if I know that someone has their own class deriving from Form, but I don't know anything else about it, a code example would use:
public class MyForm : Form
I'd certainly take a firm stance against it for real code though :)
I suppose one instance where it would be close to acceptable is if the class you're prefixing with "My" is an inner class (i.e a private class declared within another class). I'm not sure if there are any naming conventions governing inner classes, but this could be one way to differentiate.
As far as I've ever seen, My is a prefix used in sample code that indicates "your stuff goes here".
It's kind of like foo. Teaching purposes only.
I've used My in 2 situations:
Way back when in my first programming classes in school
When I am doing basic 'hello world' applications to learn a language
but NEVER in production or even pseudo-production code.
I'd avoid it in production code, your type name should reflect the function its supposed to perform.
I've used it a couple of times when patching/hacking third party code, for instance replacing Controller with MyController to make it clear it is a hack, that should be approached with caution, and a bat.
I sometimes end up with a class hierarchy where I have an abstract base class with some common functionality and a couple of implementing classes that fall into two (rarely more) groups which I want to treat differently in some cases. An example would be an abstract tree node class and different branch and leaf implementations where I want to distinguish branches and leaves at some point.
These intermediate classes are then only used for "is-a" statements in flow control and they don't contain any code, although I have had cases where they "grew" some code later.
Does that seem smelly to you? In my tree example, one alternative would be to add isLeaf() / isBranch() abstract methods to the base class and implement those on the intermediate classes, but that didn't seem to be any better to me, really, unless I'd mean to have classes that could be multiple things at once.
To me, using "is-a" tests in flow control is just as smelly as using switch/case. In a good OO design, neither is needed.
Yes, deep inheritance hierarchies are a code smell anyway.
Yup, definitely a code smell -- don't code these empty classes unless you're ready to write that code into it. Think YAGNI (you aint gonna need it) -- don't do it unless you need it already.
Also, have you considered cases wherein these classes are only there to provide abstract methods, or to group them based on capabilities in terms of methods or properties?
If that's the case, maybe what you really need are interfaces, not additional abstract classes?
In general, empty classes are a code smell.
I agree your isLeaf or isBranch methods are a correct alternative.
They add information about the objects , which is helpful.
(This is because, on the super class, you can't express that subclasses are "either leaf or branch").
The two methods with opposite results might also be considered as code duplication.
You could use only one... But I would recommend return an enumerated value LEAF or BRANCH.
A class that doesn't contain any code is definitely a code-smell....
Seems alright to me, if you're going to put new functionality in later.
But if not, an enum is generally used here.
-- Edit
Though I must agree with Ber, that you shouldn't generally be using 'is-a' anyway.