Monday, 7 December 2015

Java Magazine Sept/Oct/Nov/Dec 2015 Subscribe For Free

If you haven't subscribed to the free Java Magazine published by Oracle then now would be a good time to go do it.

The Nov/Dec issue has a good article about JSoup and WebSockets.

The Sep/Oct issue has a 'Testing" focus. If you focus on the code supported articles then there is a lot of useful information in the magazine covering JUnit, JavaFX, WebDriver Grid, JMeter.

The magazine is free and published digitally so you can read it online. I recommend you subscribe.




Friday, 23 October 2015

Using FindBugs, CheckStyle and PMD from IntelliJ with QAplug to improve your Java Coding

  • A short video showing PMD, Checkstyle and Findbugs running from IntelliJ
  • Why you would want to use them
  • And hints and tips on getting the plugins working on Mac
I’m always looking for simple ways that I can improve my Java programming.

Recently I’ve been working with PMD and Findbugs in my IDE.

I stumbled across the QAPlug, IntelliJ plugin which makes it easy to bundle in the FindBugs, CheckStyle and PMD plugins.

These each check for different issues and suggestions but basically statically analyse either the source or compiled byte code to provide a list of suggestions.

QAPlug wraps it all up in an right click menu item to Analyze the source code and shows all the items in a handy list for you to work through.

Just make sure you double click on the lowest branch in the tree to jump right to the code position where the tool identified the issue or suggestion.

This is like having a coach sitting by you when you are writing code. And some of the suggestions the tools make you won’t understand, so you have to search and learn what they mean - forcing you to learn that little bit more about your chosen language.

And don’t take all the suggestions at face value. You choose which suggestions to act on, and you can configure the tools to warn you about some things and not others.

Over time, you might choose to add the command line and build versions of the tools into your CI process rather than just your personal coding approach.

Mac Install

Note that on my Mac I had to take some additional steps to get them working since my Mac wasn’t using Java 1.8 to run IntelliJ.

When I restarted my ide - disaster. The project wouldn’t load because the plugin couldn’t start

“cannot load project com.intellij.ide.plugins.pluginmanager$startupabortedexception…"

So I searched and this was the most relevant result for me

https://youtrack.jetbrains.com/issue/IDEA-126847

With the suggested solution being:
  • Copy bin/idea/properties to ~/Library/Preferences/IntelliJIdea14/idea.properties file.
  • cp /Applications/IntelliJ\ IDEA\ 14.app/Contents/bin/idea.properties ~/Library/Preferences/IntelliJIdea14/idea.properties
  • Change JVMVersion=1.6* to JVMVersion=1.6+ (I have JDKs 1.6, 1.7 and 1.8 installed on my machine).
  • restart IntelliJ IDEA
This seems to run it on java 1.8 - assuming you have set 1.8 to be the default jdk

Tuesday, 8 September 2015

One Day Public Training Course on 5th October in Amsterdam

I’m busy re-writing my one day training course on Java For Testers, incorporating the lessons learned from finishing the Java For Testers book, and from running the training before.

A one day public training is being held in Amsterdam on 5th October.

I try to make my face to face training work for everyone - that means, people who are more advanced, and people who are absolute beginners.

Rather than just work through Java For Testers on a page by page basis, I’ve restructured the approach and code so that absolute beginners learn by filling in the blanks. i.e. I have code, then we comment out a line, fix the line or fill in the blanks. This helps absolute beginners avoid too may syntax errors and as the day progresses the exercises have more freedom.

Alongside all of that, I have to make sure that the more advanced people aren’t just uncommenting code. So I also have to create ‘bonus point’ style exercises that offer less hints, but allow the exploration of the topic and educates people with more experience.

What’s interesting (for me) is that his has led to a different order of presentation.
  • Install
  • running tests from command line
  • IntelliJ Hints and Tips
  • Primitives and Operators
  • Primitive Wrapper Classes and static methods
  • Strings
  • Logical Operators
  • if, switch, ternary
  • Fields
  • Methods
  • Constructors
  • Create your own objects
  • Arrays and Loops
  • Collections
  • JUnit @Before, @After
  • Exceptions
  • Strings
  • Random Data
  • Dates
  • Create your own project
  • Automation Libraries and More Advanced Topics
Create your own project and setup a pom.xml is one of the last things we cover on this course, which I think is slightly counter intuitive from a normal training course, but is pretty much exactly how most of us work in the real world since we spend a lot of time working with other people’s code. Reading it, tweaking it, amending it slightly. And then adding new classes into the code base.

This should mean that it is easier to take absolute beginners forward very quickly on a day training session.

This training is being run for the public in Amsterdam on the 5th October in conjunction with Xebia.

Wednesday, 26 August 2015

Updates to Java For Testers ebook and Notes on File Path construction in Java

Print Book Proof Review

When I released the e-book version of Java For Testers, I did not immediately release it as a print book. I needed it to settle and take comments from readers first.
Last week I started on the path of creating the print version. I used leanpub to create a print ready copy and for the last few days I’ve been reviewing Java For Testers as a print ready proof. As a result I’ve made some text and code changes.
The new version has minor text and formatting changes throughout. Little things like making some class names look like code in the text. Removing a few words hear and there, adding some words hear and there. Nothing substantial for most of the chapters.
The main block of work was around the File chapter, where I rewrote all the code to avoid creating custom paths.

Use File and Paths.get and Path

I previously wrote about creating a build on travis-ci, and how some of the tests failed. And since I hadn’t investigated properly, I initially assumed that was down to file permissions on travis-ci, so I did what all good teams do, and commented out those tests on that environment because I didn’t have time to fix them.
During the proof reading it became apparent to me that the File chapter didn’t represent how I build up paths in the real world. And perhaps, what I was really seeing was a cross platform issue. I hadn’t really made all the code cross platform, so I started to do that.
The first thing was to make sure that I only had hard coded paths in tests which didn’t write to disk. Those that did write to disk needed to use System property "java.io.tmpdir".
I also needed to make sure that I build up paths in a cross platform way. Since the Java file operations on Windows will happily work when your separator is ‘/’, I naively assumed that this would generate cross-platform test code. And since the tests were running on Mac, I naively assumed that it as a travis-ci problem.
However looking at the output from the tests, it was clear that on Linux, the "java.io.tmpdir" needed additional ‘/’ handling to check for it on the end of the string or not. And using File or Path means we don’t need to do that.
So I converted all the path construction code and File chapter to use a combination of File, Path and Paths.get. And lo, the code passed on Windows, Mac and travis-ci Linux.

Java For Testers supports Mac, Windows and Linux

A win-win result, and now the code runs cleanly cross platform, and the travis-ci build uses the pom.xml with no exclusions necessary.

So now, I run the code on Windows and Mac locally. Then use travis-ci to run on Linux, using JDK7, JDK8 and Open JDK 7.
Also the book now supports use on a Mac consistently throughout, since I’ve updated the install instructions to include Mac, and describe Mac specific IntelliJ shortcuts and folders etc.
The e-book changes have been released on leanpub.com, and I’ve uploaded a new version of the kindle epub to Amazon as well.

Updates to Java For Testers

A summary of the changes:
  • Amended the cover slightly.
  • Added some installation instructions to support maven on Mac
  • Updated new project process for Intellij 14
  • Updated the install page on the JavaForTesters.com site
  • fixed code sample in chapter 1 to be in chapter 1 code base
  • fixed the description of ++ and – prefix incrementing
  • Chapter 14 - added some extra code in the text to show the hamcrest assertThat more clearly
  • Chapter 15 - rewrote the description of regionMatches
  • Chapter 17 Made Dates and Time exercise cross platform - added extra code to exercise answer
  • changed the Properties chapter and File chapter (chapters 18 and 19)
    • The initial examples show building a path by string concatenation
    • Changed this to use File constructors
    • Where path is long, I have added in Paths.get and Path
    • Added information about $TMPDIR on Mac to match %TEMP% on Windows
    • All file code now uses File and Paths.get to build paths rather than concatenate strings
  • Added some extra IntelliJ Hints and tips.
(I should receive new paper proof copies over the next few days, so hopefully a paperback version of Java For Testers won’t take long to rear its head.)

Friday, 17 July 2015

Using travis-ci.org for checking code on github

I run all the tests for Java For Testers prior to releasing the book. Since all code shown in the book is pulled out of the source, it should mean that all the source code you see in the book should run.
I thought it would be useful to have a second execution of the code after it has been released to github. (I have the code with all annotations I need to 'pull' chunks out, in a different repo, then release the code with annotations removed, to github)
Travis-CI.org looked like a potential candidate since it seemed pretty simple to setup.
With Travis-CI.org, all I had to do was authenticate with my github credentials, then select the Java For Testers code repo:
The first thing travis told me was that I didn't have a .travis.yml file, so I read the instructions on the travis-ci.org site, and it couldn't find my file. Since the .travis.yml file needs to be in the root of the repo.
language: java
mvn test
After moving the .travis.yml file to the root, I tried again. Of course, I had mis-read the instructions so I removed mvn test from the .yml file.
language: java
I found the Travis-CI.org yaml file validator lint.travis-ci.org useful at this point. And used it for all future changes.
And then, since my src folder is not at the root of the repo, since I might need to release other assets along with the code to support the book. Well, Travis-CI.org couldn't find the pom.xml.
I added a build line into the .travis.yml file
language: java
script: mvn test -f ./source/pom.xml
And now everything started building. With a few failing @Test methods.
See the @Test methods in Java For Testers aren't strictly unit tests, so they do interact with the file system and create files. And some of the examples have hard coded paths which readers will be able to amend, and which work fine on my local machine, but which fail on Travis-CI.org. In theory, I could probably amend the examples in the book, but that might make them a little more complicated and confusing. And since this CI run is a 'secondary' check, I decided instead to exclude the File tests from the Travis-CI.org build.
(I will probably try and learn more about Travis-CI and revisit this decision in the future) And rather than using JUnit suites to do this, I simple excluded them via maven configuration in the plugins section.
<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-surefire-plugin</artifactId>
    <version>2.18.1</version>
    <configuration>
    <excludes>
    <!-- exclude file tests from travis-ci.org execution -->
        <exclude>**/FileTest.java</exclude>
        <exclude>**/FileExercisesTest.java</exclude>
        <exclude>**/PropertiesTest.java</exclude>
        <exclude>**/PropertyExercisesTest.java</exclude>
    </excludes>
    </configuration>
</plugin>
see inclusion-exclusion on the maven site for more details.
Of course, now I needed to create a new pom.xml purely forTravis-CI.org, but that was easy enough so now my .travis.yml file looks as follows:
language: java
script: mvn test -f ./source/travis-ci-pom.xml
And at this point, I get to see that some of my exercise answer code has some locale dependency. Specifically in the calendar exploration.
I originally wrote an answer to one of my examples as follows:
    
@Test
public void experimentWithCalendarConstants(){
  Calendar cal = Calendar.getInstance();
  cal.set(2013, Calendar.DECEMBER, 15, 23,39, 54);

  assertThat(cal.get(Calendar.DAY_OF_WEEK), is(1));
  assertThat(cal.get(Calendar.DAY_OF_WEEK), is(Calendar.SUNDAY));
  assertThat(cal.get(Calendar.WEEK_OF_MONTH), is(2));
  assertThat(cal.get(Calendar.WEEK_OF_YEAR), is(50));
  assertThat(cal.get(Calendar.DAY_OF_YEAR), is(349));
}
I specifically avoided instantiating Calendar with locale examples because I thought it would introduce additional complexity into the code, but of course, Travis-CI.org isn't based in the UK so has a different set of date defaults, which only become apparent when using the WEEK_OF_MONTH and WEEK_OF_YEAR calculations.
So I added additional configuration into the example to control the First Day of Week and Minimal Days In First Week
        cal.setFirstDayOfWeek(Calendar.MONDAY);
        cal.setMinimalDaysInFirstWeek(6);
If I was going to make the code robust then I'd really set the locale properly. e.g. per this stackoverflow example
I chose to make the code in the book simple, knowing that it was primarily going to guide the creation of code to support testing, and that code normally runs under fairly tight configuration. i.e. it doesn't go out and have to run on multiple devices and lots of operating systems. And if your test code does, then it is at that point that you usually learn to handle the platform differences that are relevant for you specific execution context.
Since Travis-CI.org has the facility to easily build against multiple JDKs, yes, I took advantage of that too.
jdk:
  - oraclejdk8
  - oraclejdk7
  - openjdk7
This is something that I didn't do locally, so is a handy bonus for the build.
All told, I found this a useful experiment and exercise. And now I have a secondary build to help, and you can see the status of that build on Travis-CI.org

Friday, 6 March 2015

How to learn to code Java without using a 'main' method

In the book Java For Testers, I teach Java slightly differently to make it easier to learn. Let me explain how.



When you learn Java, one of the first things you traditionally learn is how to create a 'main' method.

That makes sense right?

After all:

  • You're learning how to write applications. 
  • Applications need to be compiled. 
  • A compiled Java application needs a main method to run.

Of course, you also need to know:


And you might need to know:



jar cmf manifest.mf helloworld.jar HelloWorld.class

java -jar helloworld.jar

And if you are beginning your learning in how to program Java, then you don't even understand the code you've written to write "Hello World" to the console

System.out.println("Hello World");

I wonder why people prefer to learn scripting languages like Python and Ruby?

But, you don't have to learn all this when you start, especially not when you want to learn to write automation code rather than application code.

You could:

  • Write all your code in an IDE
  • Write JUnit @Test methods
  • Run the JUnit @Test methods from the IDE 
    • (right click on the method name and choose "Run")


That way, you can start to learn the Java programming language. And use it to "do stuff" without all the baggage.

That's why in the book Java For Testers, you learn to write all your code as JUnit @Test methods.

And of course, our evil, manipulative subtext... you'll also start your career in Java programming by learning "Test First". So you're learning TDD and you might not even realise it.

Sneaky, but, what did you expect from the people behind EvilTester.com

Java For Testers is a tutorial guide. Learn Java by writing JUnit @Test code.

Java For Testers ebook available from:



Wednesday, 4 March 2015

Java For Testers ebook now on Amazon

 Buy Java For Testers ebook on Amazon.com
Java For Testers ebook is now on Amazon. [amazon.co.uk][amazon.com]

The same book as available on leanpub.com [see announcement]

All I changed was the copyright page to reflect Compendium Developments Ltd as the publisher.

For those of you who want to publish through leanpub and want to do this (I used the epub editor in calibre to make the changes)

Amazon has a fixed price for the ebook, and you'll receive notifications of updates to the ebook if you have Amazon set up to tell you about them.

Leanpub has a more flexibile pricing structure, so you can pay more for the book (if you think it is worth more) (or less, if you're not sure). You will also receive more email updates, and the possibility of 'bonus extras' because I can use the leanpub mailing facility to let you know about new 'Java For Testers' information.

I personally, receive more money if you buy through leanpub, and have the ability to keep in touch easier, but I've added the ebook to Amazon for wider reach world wide.

Choose the platform you are most comfortable with. If you buy on Amazon, you can always sign up to our newsletter if you want email updates.

Java For Testers ebook available from: [amazon.co.uk][amazon.com][leanpub.com]



Tuesday, 3 March 2015

Java For Testers ebook Done and Released to Leanpub

Buy Java For Testers ebook on leanpub.com
At the end of February 2015 I released the 100% version of Java For Testers on leanpub.

If you ever wanted to learn how to code in Java, but found other beginner books hard to read or work through then this tutorial guide should help.

I focus on the core features of Java to help you achieve a lot, without overloading you, and I concentrate on the main language constructs and core libraries that I use when writing automation code.

Most Java books will have your writing manifest files, writing 'main' methods, and using the javac compiler from the command line. All of which adds extra complexity when you are trying to learn the basics.

With Java For Testers, you write and run all your code from the IDE. You will learn to write code test first with 'JUnit @Test' methods, and you'll run them from the IDE. This makes learning a lot easier.

Most Java books will have you writing Swing or JavaFX GUIs. You won't learn that in Java For Testers, because you won't need it. The IDE or the Continuous Integration system will be the GUI you use for executing automation.

After 10+ years of writing Java, I've only just written my first piece of GUI code, and that's because I'm writing an application to help my testing. Once you've followed Java For Testers, learning how to write a 'main' method and create an application will not take you long to learn. But I don't think you need it as one of the first things you learn.

The book now has:

  • 23 chapters
  • more exercises
  • more explanations
  • a Large Appendix with code for all the exercise answers
Because of all the easy to follow code examples in the body of the text, it is fairly fast to read, but you do need to spend the time working on the examples and exercises so that you gain practical experience of writing Java JUnit @Test code.


  •     Introduction
  •     Chapter One - Basics of Java Revealed
  •     Chapter Two - Install the Necessary Software
  •     Chapter Three - Writing Your First Java Code
  •     Chapter Four - Work with Other Classes
  •     Chapter Five - Working with Our Own Classes
  •     Chapter Six - Java Classes Revisited- Constructors, Fields, Getter & Setter Methods
  •     Chapter Seven - Basics of Java Revisited
  •     Chapter Eight - Selections and Decisions
  •     Chapter Nine - Arrays and For Loop Iteration
  •     Chapter Ten - Introducing Collections
  •     Chapter Eleven - Introducing Exceptions
  •     Chapter Twelve - Introducing Inheritance
  •     Chapter Thirteen - More About Exceptions
  •     Chapter Fourteen - JUnit Explored
  •     Chapter Fifteen - Strings Revisited
  •     Chapter Sixteen - Random Data
  •     Chapter Seventeen - Dates and Times
  •     Chapter Eighteen - Properties and Property Files
  •     Chapter Nineteen - Files
  •     Chapter Twenty - Math and BigDecimal
  •     Chapter Twenty One - Collections Revisited
  •     Chapter Twenty Two - Advancing Concepts
  •     Chapter Twenty Three - Next Steps
  •     Appendix - IntelliJ Hints and Tips
  •     Appendix - Exercise Answers


Full contents are available on the leanpub site :  leanpub.com/javaForTesters

You can read or download a sample of the book containing:


  •     Introduction
  •     Chapter One - Basics of Java Revealed
  •     Chapter Two - Install the Necessary Software
  •     Chapter Three - Writing Your First Java Code
  •     Chapter Four - Work with Other Classes
  •     Chapter Twenty Three - Next Steps
  •     Appendix - IntelliJ Hints and Tips


This should be good enough to get you started, for free.

The downloadable source code: [github.com/eviltester/javaForTestersCode]

  • structured into packages for each chapter
  • packages for 'examples' and 'exercises'
  • all code runs clean from 'mvn test'
  • you could add to a CI system if you wanted


All the code in the book is extracted from the downloadable source code, so there should be no code typos in the book.

All code is executed using the JUnit Test Runner, by annotating methods with @Test. So there is no need to build an executable or fiddle with manifest files.

This is the book I wanted to give people working for me when they started out learning to code for automation. And it covers the basics that I expect people to know in interviews when they say they can write automation code in Java.

Full details are over on the  leanpub.com/javaForTesters page.

Wednesday, 21 January 2015

Switching between Java versions on a Mac


I just installed JDK 1.8 and had a problem:
  1. I could not figure out where JAVA_HOME was configured
  2. I wanted an easy way to switch between versions
After a bit of Google searching I learned about:
The above article explains:


  • /usr/libexec/java_home 

  • displays the current Java version in use


  • /usr/libexec/java_home -V

  • displays all current Java versions available


  • /usr/libexec/java_home -v1.6

  • displays the path for the specific version

  • And in the above article, I found a comment describing aliases.

    I added the following aliases into my .profile

    alias java6="export JAVA_HOME=`/usr/libexec/java_home -v1.6`"
    alias java7="export JAVA_HOME=`/usr/libexec/java_home -v1.7`"
    alias java8="export JAVA_HOME=`/usr/libexec/java_home -v1.8`"

    After executing "source .profile" the aliases became active.

    And now I can easily switch between the various versions of Java.

    Notes:

    • Do not add spaces in the alias between 'java6 = "export' or your alias won't work
    • Other options are listed at mike.mainguy
    • Steve Bennett suggested jenv.be as another alternative