stability-explorer.testability-explorer.1.3.3.source-code.messages.properties Maven / Gradle / Ivy

Go to download
Show more of this group Show more artifacts with this name
Show all versions of testability-explorer Show documentation
A tool that looks at java bytecodes and helps you identify hard to test code.
The newest version!
###
#
#  Copyright 2007 Google Inc.
#
#  Licensed under the Apache License, Version 2.0 (the "License"); you may not
#  use this file except in compliance with the License. You may obtain a copy of
#  the License at
#
#  http://www.apache.org/licenses/LICENSE-2.0
#
#  Unless required by applicable law or agreed to in writing, software
#  distributed under the License is distributed on an "AS IS" BASIS, WITHOUT
#  WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the
#  License for the specific language governing permissions and limitations under
#  the License.
#
###

###
# US-English message bundle for the testability explorer reports.
# It contains some HTML markup, so it's intended to be displayed in HTML.
# TODO(alexeagle): we'll probably want to render issues in other contexts, like the CLI or IDE
#
# @author [email protected] (Alex Eagle)
###


report.title=Testability Report
report.timestamp=Report generated on: {0,date,yyyy-MM-dd hh:mm:ss}

report.explain.linkToWiki=Why is it bad?
report.explain.onLine=On line
report.explain.aroundLine=\
  Around line
report.explain.contribution=Contribution
to class cost

report.explain.class.hardToTest=Class {0}{1}{2} is hard to test because:

###
# Hard to test due to construction of the class
###
report.explain.class.construction=\
  It is expensive to construct an instance of the class, and every test will need to call a constructor.
report.explain.class.construction.static_init=\
  These static initializers will need to be run once, when the class is loaded.
report.explain.class.construction.static_init.element={0}static {1}{2} is declared
report.explain.class.construction.static_init.suggest=\
  Instead of initializing this state statically, try initializing a fresh copy in each instance. \
  Creating new objects in Java is cheap, and this static state can't be cleaned up between tests.
report.explain.class.construction.static_method=Static methods are called in constructor
report.explain.class.construction.static_method.element=static method {0}{1}{2} is called
report.explain.class.construction.static_method.suggest=\
  This couples every test to use the code in the static method. \
  Refactor the static method to be an instance method on the class.
report.explain.class.construction.setter=Setters will need to be called by tests
report.explain.class.construction.setter.element=\
  Setter method {0}{1}{2} may need to be called before some methods can be tested
report.explain.class.construction.setter.suggest=\
  Setter methods should avoid doing serious work. Instead, the \
  initialized state should be passed to the setter.
report.explain.class.construction.non_mockable=You are calling new in the constructor
report.explain.class.construction.non_mockable.element=new instance of {0}{1}{2} created
report.explain.class.construction.non_mockable.suggest=\
  Using new couples this class to the one instantiated, \
  preventing you from testing this class in isolation of that collaborator. \
  Instead, pass an instance of the collaborator as a new constructor parameter.
report.explain.class.construction.complexity=Constructors with a high cyclomatic complexity
report.explain.class.construction.complexity.element={0}{1}{2} is complex
report.explain.class.construction.complexity.suggest=\
  Don't perform work in the constructor. Instead, initialize all the needed state, and pass \
  it as a new parameter.

report.explain.class.construction.singleton=A singleton is used
report.explain.class.construction.singleton.element=mutable global field {0}{1}{2} is declared
report.explain.class.construction.singleton.suggest=Don't use singletons. Instead, use a \
  dependency injection framework or factory that always returns the same instance.

#report.explain.class.staticInit=Static initializers must be run:
#report.explain.class.staticInit.variable=a static member variable {0} is initialized to a value that is complex to evaluate.
#report.explain.class.staticInit.suggest=Suggestion: these static members are complex. Instantiate the values outside this class, and pass them as parameters to the constructor.

#report.explain.class.constructor=The constructor does work:
#report.explain.class.constructor.methodExec=in the constructor, {0} is executed, which has a high complexity.
#report.explain.class.constructor.suggest=Suggestion: tests will have to execute this code to create an instance. Do this work outside the class, and pass the needed state as a parameter to the constructor. If this is impossible, at least move this code to an initialization method.

###
# Hard to test due to non-mockable collaborators
###
report.explain.class.collaborator=\
  These collaborators cannot be mocked, so it is impossible to unit test this class in isolation.

report.explain.class.collaborator.static_method=Static methods are called:
report.explain.class.collaborator.static_method.element=static method {0}{1}{2} is called
report.explain.class.collaborator.static_method.suggest=\
  Since these static methods are complex, we want to mock them out in the unit test. \
  If they are declared in your code, refactor the methods to be non-static, \
  and inject an instance of the class. Otherwise, you can create a wrapper object.

report.explain.class.collaborator.non_mockable=Non-mockable collaborators:
report.explain.class.collaborator.non_mockable.element={0}{1}{2} is called
# TODO(alexeagle): figure out which reason is the right one here
report.explain.class.collaborator.non_mockable.suggest=\
  This method call can't be mocked out from a unit test because the test cannot \
  control how the object is instantiated. This can be caused by: \
  - the object was created using new, \
  - it was returned by a non-mockable collaborator, or \
  - the method is declared final or private, which prevents overriding in a subclass

report.explain.class.collaborator.singleton=Singletons are used:
report.explain.class.collaborator.singleton.element=mutable global state is accessed by {0}{1}{2}
report.explain.class.collaborator.singleton.suggest=\
  Don't use singletons. Instead, use  \
  dependency injection and always inject the same instance.

###
# Hard to test because of direct costs
###
report.explain.class.directCost=\
  The code itself is complex, and it will be hard to test all the different paths of execution
report.explain.class.directcost.complexity=\
  There are complicated methods
report.explain.class.directcost.complexity.element=method {0}{1}{2} has high complexity
report.explain.class.directcost.complexity.suggest=\
  Refactor the method by breaking the complex portions into several smaller methods.

###
# Hard to test because of mutable global state
###

###
# Makes other code hard to test
###
#report.explain.class.impactOnOthers=This class may make it hard to test other code that uses it because:
#report.explain.class.staticVars=Static variables need to be set to the correct state
#
report.explain.class.benefits=If these changes were made, the cost of testing this class would be reduced by {0}{1,number,##%}{2}.



################################
#
# The "About Testability" report
#
################################
report.about.title=Examples of how Testability works
report.about.description=Testability explorer analyzes compiled classes, looking for issues in your code that make it difficult to unit test. \
  Each class below is an example of a particular bad practice, and is followed by the explanation of the issues that are found in that code. \
  To make the examples short, the issues in this code are minor. To demonstrate the report, the sensitivity has been set artificially high.\
  Normally, these issues would not be reported. \
  To create a report like this for your code, see the Testability Explorer website.
report.about.class=Example class: {0}{1}{2}