• Splits up CSV records using a custom field separator
• That is all for now in terms of documentation!

...test automation is the use of special software (separate from the software being tested) to control the execution of tests and the comparison of actual outcomes with predicted outcomes. Test automation can automate some repetitive but necessary tasks..., or perform additional testing that would be difficult to do manually [1].

• Replaces manual labor by means of automation
• Creates easily repeatable tests
• Quick result to qualify changes
• Will pay off in the long run
• Require predictable outcome
• Upfront investment

In computer programming, unit testing is a software testing method by which individual units of source code, sets of one or more computer program modules together with associated control data, usage procedures, and operating procedures, are tested to determine whether they are fit for use [2].

UNIT TESTING is a level of software testing where individual units/ components of a software are tested. The purpose is to validate that each unit of the software performs as designed. A unit is the smallest testable part of any software. It usually has one or a few inputs and usually a single output [1].

By the Books

• Unit test is a test type
• It defines what to test
• It doesn't define how to test
• It doesn't say that this is by code or for code

• Is it the smallest part?
• How can I reach it? Is it just code?
• What are the possible ways to test it?
• Does it have dependencies?
  • Database
  • File system
  • Some other state or data container
  • System dependencies aka OS or setup

Test Automation

• Finding ways to make testing quick, repeatable, predictable, and effortless
• How? Does not matter
• Use frameworks that fit

/**
 * Encodes the given fields to a CSV-encoded data record 
 * using the given field separator.
 * 
 * @param s
 *            the plain fields
 * @param fieldSeparator
 *            the field separator to use
 * @return the CSV-encoded data record
 */
public static String[] decode(final String s, final char fieldSeparator)

• Is this a public API?
• Is this an internal API?
• Is this just a piece of code that helps my feature and not for anyone else?
• Is the unit standalone enough?
• Does it have dependencies (code, data)?
• Do I have access to the code?

• Approach as blackbox first
• Use documentation to plan
• If it is not documented, use implicit knowledge aka your expectations
• Helps you to step back and see it from a different angle

• Run code coverage
• Under 100%, still work to do
• 100%, darn... not that easy anymore
• Review code for suspicious comments
• Check for assumptions made
• Check for hardcoded values
• Check for behavior that is not documented
• Check for all potential error conditions

• Application has to be designed for automation
• The better the architecture the easier to automate
• Select by priority first
• Select what is hard to test manually next
• Select by module or component
• Select by unit within

• Automation is testing, have a plan
• Writing finds more defects than running
• Vary by data
• Never forget edge-cases
• Hard to automate means either incorrect design or not really worth the effort
• Mocking can turn things into a self-fulfilling prophecy
• Do what humans can't do
• Change something, fix something? Add a test before and one after

• Automation can easily create a false impression
• Working tests don't mean that much if you have not well written and designed AND reviewed tests
• Changes to tests should make your nervous
• Adding tests is ok, removing tests is mostly not ok
• Automation is coding, hence it can contains the same defects
• Review your automation like any other code
• Document automation code like any other code

/**
 * Split a string at spaces
 * @param s the string to split
 * @return a list with substrings without the dividing space
 */
public List<String> split(final String s)
{
    final List<String> result = new ArrayList<>();
    
    int lastPos = 0;
    for (int i = 0; i < s.length(); i++)
    {
        final char c = s.charAt(i);
        if (c == ' ')
        {
            result.add(s.substring(lastPos, i));
            
            lastPos = i + 1;
        }
    }
    
    // deal with remainder
    if (lastPos != s.length())
    {
        result.add(s.substring(lastPos));            
    }
    
    return result;
}

@Test
public void test()
{
    split("AB");
}

• 0% coverage tells us something
• <100% tells us something
• 100% tells us that it is not simple anymore to add tests
• It cannot be used to judge test coverage
• It cannot be used to judge test quality
• If you cannot reach 100% code coverage, you code logic is broken

Code refactoring is the process of restructuring existing computer code ... without changing its external behavior. Refactoring improves nonfunctional attributes of the software. ...improved code readability and reduced complexity; ...improve source-code maintainability and create a more expressive internal architecture ... to improve extensibility [1].

• When you touch things, you break things
• Ensure that the behavior and functionality stays the same
• Ensure that the result is better code, not worse
• Better code is hardly measurable

• Define inner and outer behavior
• Fix up outer behavior with tests
  • Unit tests
  • API tests
  • Integration tests
  • Whatever is necessary
• Try to automate as much as possible
• Not everything can be automated or is feasible to be automated

All green with test automation, especially with unit tests, does not mean the application is working.

Red tests in the contrary always mean that the application is not working.

• Yet another map
• Simpler interface for learning
• Not compatible to JDK Collections
• Goal is to show API and unit test design