I've recently started to try to use Dist::Zilla for maintaining Path::Class. I added the [PodCoverageTests] plugin, and it's reporting some failures in the Path::Class::Entity class, which is the abstract base class for Path::Class::File and Path::Class::Dir.
What I'd like is some way to tell the testing code that Entity doesn't need docs, but its two derived classes do - even though the methods are only defined in the parent class. Anyone know some way to do that?
Dist::Zilla's standard POD coverage test uses Pod::Coverage::TrustPod.
You should be able to say
=for Pod::Coverage
.
to tell it to assume that everything is documented.
Related
I'm just looking into Scala and I have a couple of questions regarding the best way to share common attributes like loggers, database handles and configuration across classes without passing them around.
We could make a singleton class which would have the logger, handle and application but this seems wrong to me since and any subclassing the singleton isn't a more specialised case.
I see that Scala has the concept of a trait which I believe is like a mixin. Is it possible - and good practice if it is - to combine a trait with a singleton? If not what is the recommended approach?
The best practice to share common entities throughout the package is by declaring them in the package object file.
Refer here https://alvinalexander.com/scala/scala-package-objects-how-to-name-location-cookbook-recipe
This is a big subject and there is no single correct best approach - your question is quite broad. Here are some areas I would spend some time reading up on if you want to get the bigger picture:-
Mixin traits are a popular way of decorating classes with reusable behaviours - a custom logger being a good example. Assuming you really do need to customise a logging libraries behaviour that is.
For configuration and database connections, mixin traits work as well but some frameworks eg. Play use dependency injection as a way for classes to obtain their dependencies. Note that there are both compile time and runtime DI frameworks.
Another, less common, approach that is arguably more complex is to use aspects (AOP) - https://www.google.co.uk/search?ei=1iN-W6neNePWgAb05orYAQ&q=scala+aop&oq=scala+aop
If you are just starting out then choose some popular libraries - read their docs - and let them guide you as to how best to adopt them, eg.
Logging - https://github.com/lightbend/scala-logging
Config - https://github.com/lightbend/config
Context:
Say I have a few modules that inherit from each other (using old-school inheritance with base and parent, not Moose or similar). Foo::Bar inherits Foo, and Foo::Bar::Baz inherits Foo::Bar. All of these modules have test suites written with Test::More. The test suite for a child class only tests the methods that it implements. Child classes do not necessarily override all methods in their parents, though they may add new methods that their parent does not have.
Question:
Is there some testing framework, technique, or Test::More feature with which I can write tests that will not only test subclass-specific behavior, but will also then run test suites for any inherited behavior/parent classes as well? Basically, I'm looking for something that allows me to write tests for the unique/special behavior of a subclass, but will also test and make sure that the subclass behaves in tests the same way that its parent class(es) are expected to.
What I've tried:
I've written a very simple test harness with a generator method that builds an instance of a string-specified module and runs tests against it depending on what type of module was requested (there's a central hash that keeps track of subclass/superclass hierarchy), but this seems crude. I'm assuming that (like most things I need to do in Perl), someone else has already done this in a much more elegant and robust way.
What you're looking for is Test::Class.
You can make a test class for Foo::Bar, which I would probably call Test::Foo::Bar. This Perl module will use Test::Class as its base class. But instead of testing Foo::Bar directly, access it through a method:
sub class {'Foo::Bar'}
This allows us to override it later.
Then you make a new test class, Test::Foo::Bar::Baz which inherits from Test::Foo::Bar. By doing this, you've automatically inherited all the tests you wrote for the parent class. Of course you'll need to override class():
sub class {'Foo::Bar::Baz'}
Voila! You're now running all your tests from Test::Foo::Bar on Foo::Bar::Baz, and you're free to override or make new tests to your heart's content.
Chromatic has a thorough example on his blog: Resuing Test Code with Test::Class
And you're right about test harnesses already existing. A mixture of Test::Class, Test::Harness, and prove should take care of your needs, and there's very little reason to write your own.
Using perl and TAP, I have written a lot of selenium tests and saved them in *.t files.
I have created some helper functions, put them into a non-object oriented package, say My::Util::SeleniumHelper.
All functions are exported from this module.
In the beginning, one package was sufficient, now the single-module API contains quite a few unrelated functions. These functions are called, for example make_sel(),
head_ok(),
cms_logout(),
cms_login(),
cms_clickthru_simple(),
selenium_rc_running(),
treecontrol_toggles() - you get the idea.
Moreover, many blocks of code in the t-files are still redundant, making the .t file look like a template.
Thus, I want to give my *.t code a more OO design.
Any ideas on how to design the new API?
Essentially, I am also looking for code examples (here, or on the internet) where someone has extended the selenium object in a clever way. It does not have to be in perl.
Would it be useful to add methods to the Test::WWW::Selenium object $sel?
$sel->my_click_ok()
I should I try to override the $sel object?, Deriving a Test::WWW::Selenium::Customized class from Test::WWW::Selenium
This would violate the "Prefer composition over inheritance" idiom
Should I wrap the selenium object into another object using composition?
$myobj->{sel}->click_ok()
Here are some more requirements or thoughts:
I also want to use the pageObjects Pattern/Idiom. Not doing so yet.
Maybe so
$myobj->{current_page}->loginbox
or
$myobj->do_stuff($current_page->loginbox)
I noted that in most cases, basically, I'd like to give the selenium method something like an Moose's around() modifier. Do th standard thing, but do some things before and after.
However, I prefer to not use Moose here because the tests need to run on a few different machines, and don't want to install Moose and all its dependencies on all these PCs. I am not saying that is impossible to use moose, however I did not yet use non-moose objects (Test::WWW::Selenium) and moose objects together.
I'm using Moose and delegation to extend Test::WWW::Selenium. The only thing thats in the extension is configuration stuff (host, port, browser, etc). Everything else is in roles.
Making a custom class inheriting from the Selenium one seems completely reasonable in this case. Eric's Moose delegation solution is a little cleaner; but a bit more complicated too.
I'm subclassing Test::WWW::Selenium. new {} needs to call SUPER, but then on, it looks and tastes like the parent. I've got a new open() that lints the HTML and checks links (memoized of course).
I was thinking to create a generic base class and have each of the module base class inherit from it... but is there a better way to do this?
I'd say if you need a base class, you're not having real modules. I think modules should be "totally" independent sub-applications.
If you really want to write such a base class, use dependency injection, not inheritance so you can inject the needed common behaviour in all modules without creating such a tight coupling of all your modules. Just create a subfolder under 'application' and call it 'Base' or something. But again, I think it might not be such a good idea resp. if you need it, we're not talking about modules. Then again, each case is different.
We seems to be abstracting a lot of logic way from web pages and creating "helper" classes. Sadly, these classes are all sounding the same, e.g
ADHelper, (Active Directory)
AuthenicationHelper,
SharePointHelper
Do other people have a large number of classes with this naming convention?
I would say that it qualifies as a code smell, but remember that a code smell doesn't necessarily spell trouble. It is something you should look into and then decide if it is okay.
Having said that I personally find that a name like that adds very little value and because it is so generic the type may easily become a bucket of non-related utility methods. I.e. a helper class may turn into a Large Class, which is one of the common code smells.
If possible I suggest finding a type name that more closely describes what the methods do. Of course this may prompt additional helper classes, but as long as their names are helpful I don't mind the numbers.
Some time ago I came across a class called XmlHelper during a code review. It had a number of methods that obviously all had to do with Xml. However, it wasn't clear from the type name what the methods had in common (aside from being Xml-related). It turned out that some of the methods were formatting Xml and others were parsing Xml. So IMO the class should have been split in two or more parts with more specific names.
As always, it depends on the context.
When you work with your own API I would definitely consider it a code smell, because FooHelper indicates that it operates on Foo, but the behavior would most likely belong directly on the Foo class.
However, when you work with existing APIs (such as types in the BCL), you can't change the implementation, so extension methods become one of the ways to address shortcomings in the original API. You could choose to names such classes FooHelper just as well as FooExtension. It's equally smelly (or not).
Depends on the actual content of the classes.
If a huge amount of actual business logic/business rules are in the helper classes, then I would say yes.
If the classes are really just helpers that can be used in other enterprise applications (re-use in the absolute sense of the word -- not copy then customize), then I would say the helpers aren't a code smell.
It is an interesting point, if a word becomes 'boilerplate' in names then its probably a bit whiffy - if not quite a real smell. Perhaps using a 'Helper' folder and then allowing it to appear in the namespace keeps its use without overusing the word?
Application.Helper.SharePoint
Application.Helper.Authentication
and so on
In many cases, I use classes ending with Helper for static classes containing extension methods. Doesn't seem smelly to me. You can't put them into a non-static class, and the class itself does not matter, so Helper is fine, I think. Users of such a class won't see the class name anyway.
The .NET Framework does this as well (for example in the LogicalTreeHelper class from WPF, which just has a few static (non-extension) methods).
Ask yourself if the code would be better if the code in your helper class would be refactored to "real" classes, i.e. objects that fit into your class hierarchy. Code has to be somewhere, and if you can't make out a class/object where it really belongs to, like simple helper functions (hence "Helper"), you should be fine.
I wouldn't say that it is a code smell. In ASP.NET MVC it is quite common.