There are two ways in which abstract base classes are used.
You are specializing your abstract object, but all clients will use the derived class through its base interface.
You are using an abstract base class to factor out duplication within objects in your design, and clients use the concrete implementations through their own interfaces.!
Solution For 1 - Strategy Pattern
If you have the first situation, then you actually have an interface defined by the virtual methods in the abstract class that your derived classes are implementing.
You should consider making this a real interface, changing your abstract class to be concrete, and take an instance of this interface in its constructor. Your derived classes then become implementations of this new interface.
This means you can now test your previously abstract class using a mock instance of the new interface, and each new implementation through the now public interface. Everything is simple and testable.
Solution For 2
If you have the second situation, then your abstract class is working as a helper class.
Take a look at the functionality it contains. See if any of it can be pushed onto the objects that are being manipulated to minimize this duplication. If you still have anything left, look at making it a helper class that your concrete implementation take in their constructor and remove their base class.
This again leads to concrete classes that are simple and easily testable.
As a Rule
Favor complex network of simple objects over a simple network of complex objects.
The key to extensible testable code is small building blocks and independent wiring.
Updated : How to handle mixtures of both?
It is possible to have a base class performing both of these roles... ie: it has a public interface, and has protected helper methods. If this is the case, then you can factor out the helper methods into one class (scenario2) and convert the inheritance tree into a strategy pattern.
If you find you have some methods your base class implements directly and other are virtual, then you can still convert the inheritance tree into a strategy pattern, but I would also take it as a good indicator that the responsibilities are not correctly aligned, and may need refactoring.
Update 2 : Abstract Classes as a stepping stone (2014/06/12)
I had a situation the other day where I used abstract, so I'd like to explore why.
We have a standard format for our configuration files. This particular tool has 3 configuration files all in that format. I wanted a strongly typed class for each setting file so, through dependency injection, a class could ask for the settings it cared about.
I implemented this by having an abstract base class that knows how to parse the settings files formats and derived classes that exposed those same methods, but encapsulated the location of the settings file.
I could have written a "SettingsFileParser" that the 3 classes wrapped, and then delegated through to the base class to expose the data access methods. I chose not to do this yet as it would lead to 3 derived classes with more delegation code in them than anything else.
However... as this code evolves and the consumers of each of these settings classes become clearer. Each settings users will ask for some settings and transform them in some way (as settings are text they may wrap them in objects of convert them to numbers etc.). As this happens I will start to extract this logic into data manipulation methods and push them back onto the strongly typed settings classes. This will lead to a higher level interface for each set of settings, that is eventually no longer aware it's dealing with 'settings'.
At this point the strongly typed settings classes will no longer need the "getter" methods that expose the underlying 'settings' implementation.
At that point I would no longer want their public interface to include the settings accessor methods; so I will change this class to encapsulate a settings parser class instead of derive from it.
The Abstract class is therefore: a way for me to avoid delegation code at the moment, and a marker in the code to remind me to change the design later. I may never get to it, so it may live a good while... only the code can tell.
I find this to be true with any rule... like "no static methods" or "no private methods". They indicate a smell in the code... and that's good. It keeps you looking for the abstraction that you have missed... and lets you carry on providing value to your customer in the mean time.
I imagine rules like this one defining a landscape, where maintainable code lives in the valleys. As you add new behaviour, it's like rain landing on your code. Initially you put it wherever it lands.. then you refactor to allow the forces of good design to push the behaviour around until it all ends up in the valleys.
Karma is a JavaScript test-runner built with Node.js and meant for unit testing.
The Protractor is for end-to-end testing and uses Selenium Web Driver to drive tests.
Both have been made by the Angular team. You can use any assertion-library you want with either.
Screencast: Karma Getting started
related:
pros:
- Uses node.js, so compatible with Win/OS X/Linux
- Run tests from a browser or headless with PhantomJS
- Run on multiple clients at once
- Option to launch, capture, and automatically shut down browsers
- Option to run server/clients on development computer or separately
- Run tests from a command line (can be integrated into ant/maven)
- Write tests xUnit or BDD style
- Supports multiple JavaScript test frameworks
- Auto-run tests on save
- Proxies requests cross-domain
- Possible to customize:
- Extend it to wrap other test-frameworks (Jasmine, Mocha, QUnit built-in)
- Your own assertions/refutes
- Reporters
- Browser Launchers
- Plugin for WebStorm
- Supported by Netbeans IDE
Cons:
I'm totally unqualified to comment on mocha.js's features, strengths, and weaknesses,
but it was just recommended to me by someone I trust in the JS community.
List of features, as reported by its website:
- browser support
- simple async support, including promises
- test coverage reporting
- string diff support
- javascript # API for running tests
- proper exit status for CI support etc
- auto-detects and disables coloring for non-ttys
- maps uncaught exceptions to the correct test case
- async test timeout support
- test-specific timeouts
- growl notification support
- reports test durations
- highlights slow tests
- file watcher support
- global variable leak detection
- optionally run tests that match a regexp
- auto-exit to prevent "hanging" with an active loop
- easily meta-generate suites & test-cases
- mocha.opts file support
- clickable suite titles to filter test execution
- node debugger support
- detects multiple calls to done()
- use any assertion library you want
- extensible reporting, bundled with 9+ reporters
- extensible test DSLs or "interfaces"
- before, after, before each, after each hook
- arbitrary transpiler support (coffee-script etc)
- TextMate bundle
This no longer exists, redirects to sequential.js instead
Yolpo is a tool to visualize the execution of javascript. Javascript API developers are encouraged to write their use cases to show and tell their API. Such use cases forms the basis of regression tests.
Futuristic test runner with built-in support for ES2015. Even though JavaScript is single-threaded, IO in Node.js can happen in parallel due to its async nature. AVA takes advantage of this and runs your tests concurrently, which is especially beneficial for IO heavy tests. In addition, test files are run in parallel as separate processes, giving you even better performance and an isolated environment for each test file.
- Minimal and fast
- Simple test syntax
- Runs tests concurrently
- Enforces writing atomic tests
- No implicit globals
- Isolated environment for each test file
- Write your tests in ES2015
- Promise support
- Generator function support
- Async function support
- Observable support
- Enhanced asserts
- Optional TAP o
utput
- Clean stack traces
A JavaScript test-runner built with Node.js. Very modular and flexible. It comes with its own assertion library, but you can add your own if you like. The assertions library is decoupled, so you can also use it with other test-runners. Instead of using assert(!...)
or expect(...).not...
, it uses refute(...)
which is a nice twist imho.
A browser JavaScript testing toolkit. It does browser testing with browser automation (think JsTestDriver), QUnit style static HTML page testing, testing in headless browsers (PhantomJS, jsdom, ...), and more. Take a look at the overview!
A Node.js testing toolkit. You get the same test case library, assertion library, etc. This is also great for hybrid browser and Node.js code. Write your test case with Buster.JS and run it both in Node.js and in a real browser.
Screencast: Buster.js Getting started (2:45)
pros:
- Uses node.js, so compatible with Win/OS X/Linux
- Run tests from a browser or headless with PhantomJS (soon)
- Run on multiple clients at once
- Supports NodeJS testing
- Don't need to run server/clients on development computer (no need for IE)
- Run tests from a command line (can be integrated into ant/maven)
- Write tests xUnit or BDD style
- Supports multiple JavaScript test frameworks
- Defer tests instead of commenting them out
- SinonJS built-in
- Auto-run tests on save
- Proxies requests cross-domain
- Possible to customize:
- Extend it to wrap other test-frameworks (JsTestDriver built in)
- Your own assertions/refutes
- Reporters (xUnit XML, traditional dots, specification, tap, TeamCity and more built-in)
- Customize/replace the HTML that is used to run the browser-tests
- TextMate and Emacs integration
Cons:
- Stil in beta so can be buggy
- No plugin for Eclipse/IntelliJ (yet)
- Doesn't group results by os/browser/version like TestSwarm *. It does, however, print out the browser name and version in the test results.
- No history of previous test results like TestSwarm *
- Doesn't fully work on windows as of May 2014
* TestSwarm is also a Continuous Integration server, while you need a separate CI server for Buster.js. It does, however, output xUnit XML reports, so it should be easy to integrate with Hudson, Bamboo or other CI servers.
https://github.com/jquery/testswarm
TestSwarm is officially no longer under active development as stated on their GitHub webpage. They recommend Karma, browserstack-runner, or Intern.
This is a behavior-driven framework (as stated in quote below) that might interest developers familiar with Ruby or Ruby on Rails. The syntax is based on RSpec that are used for testing in Rails projects.
Jasmine specs can be run from an html page (in qUnit fashion) or from a test runner (as Karma).
Jasmine is a behavior-driven development framework for testing your JavaScript code. It does not depend on any other JavaScript frameworks. It does not require a DOM.
If you have experience with this testing framework, please contribute with more info :)
Project home: http://jasmine.github.io/
QUnit focuses on testing JavaScript in the browser while providing as much convenience to the developer as possible. Blurb from the site:
QUnit is a powerful, easy-to-use JavaScript unit test suite. It's used by the jQuery, jQuery UI, and jQuery Mobile projects and is capable of testing any generic JavaScript code
QUnit shares some history with TestSwarm (above):
QUnit was originally developed by John Resig as part of jQuery. In 2008 it got its own home, name and API documentation, allowing others to use it for their unit testing as well. At the time it still depended on jQuery. A rewrite in 2009 fixed that, now QUnit runs completely standalone.
QUnit's assertion methods follow the CommonJS Unit Testing specification, which was to some degree influenced by QUnit.
Project home: http://qunitjs.com/
Another great tool is sinon.js by Christian Johansen, the author of Test-Driven JavaScript Development. Best described by himself:
Standalone test spies, stubs and mocks
for JavaScript. No dependencies works
with any unit testing framework.
The Intern Web site provides a direct feature comparison to the other testing frameworks on this list. It offers more features out of the box than any other JavaScript-based testing system.
A new but yet very powerful testing framework. It allows snapshot based testing as well this increases the testing speed and creates a new dynamic in terms of testing
Check out one of their talks: https://www.youtube.com/watch?v=cAKYQpTC7MA
Better yet: Getting Started
Best Answer
The rule
S2699
(Tests should include assertions) from the SonarQube Java Analyzer does not perform cross-procedural analysis and only explore body of methods being identified as test method (usually annotated with@Test
).Consequently, if the only assertions which will be called when executing the test method are done by a dedicated method (to avoid duplication), then the rule will raise an issue. This is a known limitation of the rule and we will deal with it only when we will be able to efficiently perform cross-procedural analysis.
Regarding the issues raised by SonarQube on such cases, you can safely mark them as
Won't Fix
.Regarding the detected assertions, the rule consider as assertions the usual
assert
/fail
/verify
/expect
methods from the following (unit test) frameworks :