Showing posts with label Testing. Show all posts
Showing posts with label Testing. Show all posts

Wednesday, 19 June 2013

Skimmer's Guide - Behaviour Driven Development with JavaScript




“BDD has many different aspects. Which of them are important depends on your perspective.”

WHAT IS THE ABOUT? 

Marco Emrich brings us a mature and enlightening insight into Behaviour Driven Development with JavaScript. Absolutely rammed full of excellent information, the book is nevertheless extremely well paced and reads very easily.

Beginning in earnest with a quick refresher on JavaScript, we are soon introduced to Jasmine, our JavaScript BDD weapon of choice ;) The underlying mechanics of BDD are explored (i.e. Red-Green-Refactor) before we are shown novel ways of generating data for our tests.

Particular attention is then spent on advising us how to organise/write our tests to maximise readability/maintainability. Following this we dive into Outside-In Development and how we can use it to flush out uncertainty. Use cases of the various types of 'test doubles' are covered, extensively so for mocks.

We finish by addressing the difficult question of "what is BDD?", bringing together everything we learnt into a formal methodology. The most important aspects are brought into focus and pointed in the direction of possible next steps into the BDD world.

WHAT STOOD OUT? 

JavaScript refresher (p. 7) 
Covering modern and functional aspects of JavaScript, this introductory chapter is incredible helpful for anyone rusty with JavaScript. Anyone experienced in JavaScript should probably simply skim/skip this though. 

Specs should be readable (p. 27) 
Great coverage of the DAMP/DRY principles here and throughout the chapter. Sound advice with warnings every developer should heed! 

Organising by feature or by fixture (p. 35) 
Interesting techniques for keeping tests cohesive and making them read naturally, through intelligent organisation and custom code tools. 

Using test doubles (p. 53) & Advantages and disadvantages of mocks (p. 61) 
Fantastic coverage on how and when to use dummy, stub and mock objects, including views on the pros and cons of mocking. 

Vocabulary (p. 61) 
A resonating account of the pitfalls of TDD for beginners and how an improved vocabulary better enables proper testing. 

IF YOU READ NOTHING ELSE... 

Baby Steps (p. 23) 
Wonderful teaching on the importance of having a "tight feedback loop". Emphasis it placed on how the longer it takes to find a problem, the harder it is to solve it. Taking baby steps when changing code will let you go faster! 

Triangulation (p. 42) 
A wonderful technique for "faking it until you make it", forcing you to test all the relevant paths through your code. 

Gerkin language (p. 66) & Goals and benefits (p. 67) 
Covers the fabled "Given Then When" syntax of BDD and how it isn't necessarily central to BDD.


CONCLUSION 

At less than £2.60 ($3.99) this book is insanely good value and I would highly recommend it to anyone starting to learn BDD, even if they have limited JS experience. Despite centring around JavaScript, the core concepts of BDD are covered magnificently and can be applied to any language. 

Highly accessible and easy to reference, this book definitely warrants inclusion on any developer's digital bookshelf.

Sunday, 5 May 2013

OpenJDK Test Fest (23rd March 2013)

Better late than never, I'm writing about my very first hack-day working on OpenJDK testing :)

Introduction


After LJC Conf 2012 I got interested in the Adopt OpenJDK project. Sadly it was only in early 2013 when I finally managed to get fully set up for the project. (Building Java has gotten a lot easier!)

A big issue for the OpenJDK project is that currently there are little to none open tests. Whilst Oracle and others have many prioritory tests for the JDK, they are unlikely to be released anytime soon. Hence there is a big push to improve the quality of exisiting tests and increase test coverage.

What I hope to cover in this post is:
  1. Getting started testing OpenJDK (using JTReg)
  2. Guidance on testing OpenJDK
  3. Next steps (how you can get involved!)

Getting Started - Seed project


OpenJDK tests are primarily written using a tool called JTReg. The reason behind this that the very first tests pre-date JUnit and TestNG. Sadly this does make writing OpenJDK tests a bit of a pain...

To get started easily, I recommend you utilise the seed project I set up here:
https://github.com/arkangelofkaos/OpenJdkTesting

Within it you will find a copy of JTReg and a few very simple tests to show you the basics. I highly recommend you go through the JTReg tutorial (available here).

Guidance


During the hack-day we were given a list of "Ten Golden Rules" for testing on OpenJDK, here is my take on them:
  1. Think before you code! 
    • Have a specific goal, target specific methods.
  2. Make tests understandable
    • Fill in the summary tag
    • Be clear and make your test goal explicit
  3. Make tests "small and simple"
    • Use setup and teardown as necessary.
    • Keep tests idempotent. 
    • Not cleaning up is not only impolite but can cause errors for other test cases!
  4. Test only one thing!
    • 1 assert per test = easy to understand and simple :)
  5. Fast tests only! 
    • Quick tests required as they will be run over and over.
  6. Absolute repeatability
    • Tests ONLY fail if there is a bug in the code under test.
    • One pitfall is using Thread.sleep to handle concurrency issues
      • Understand what your goal is (draw it out!)
      • Use proper concurrency tools to enforce an execution order (e.g. countdown latches)
  7. Independent tests
    • Tests should not rely on other tests or be affected by execution order.
  8. Provide diagnostic data on failure
    • Use messages on assertions and throw sensible exceptions.
  9. Ensure portability
    • Do not hardcode environment details into the test.
  10. Silence is golden
    • Only speak up if the test is broken. Don't pollute the output. 
    • However, sometimes a little additional output is very helpful for debugging.
As always with any software rules, the rules depend on the circumstance. Sometimes you will need to break these rules but it is important we understand why!

Conclusion


Java needs our help to stay relevant and increase the pace of upgrades. This means testing needs to improve and we can contribute to this through OpenJDK. If you are interested, I highly recommend you grab the seed project, join up and give it a go!

Friday, 30 November 2012

Programming Goals

Recently I have been trying to improve myself as a programmer and all round software engineer. As a part of this, I joined the London Java Community and I've been attending various meet-ups.

All my recent exploits will have to wait have to wait for another post but I just wanted to list my goals for all of this. In this way, it will be clear in my head in the very least!

Really understand Java and the JVM
  • Gain a better insight to how my Java code translates to byte-code.
  • Learn more about how the JVM runs.
  • Fully understand garbage collection, along with the G1 collector.
  • Get to grips with tuning the JVM.
Become an expert in performance optimisation
  • Learn how to truly measure performance on a macro and micro level.
  • Understand the techniques necessary to produce faster code.
  • Be fully aware of all the external factors which affect performance, such as I/O and network latency.
  • Learn more algorithms and use more in anger.
Better manage and estimate time
  • Be able to provide accurate quotes for concrete deliverables.
  • Understand the techniques to estimate for intangible/vague software requirements.
  • Better plan out work to reduce risk/maximise productivity!
Become a software design guru!
  • Weave the right software design patterns into all my code.
  • Avoid anti-patterns!
  • Make all my code simple, robust and scalable (as necessary).
Be better at testing
  • Find a practical testing framework/methodology given volatile requirements and highly limited timeframes.
  • Better express user expectations as some form of user interface tests.
  • Improve general code coverage!
Adopt a proper release management methodology
  • Find or come up with a good version number standard!
  • Set up some form of "One-click" deployment
Start benefitting from Continuous Integration 
  • Properly set up CI environment to monitor and analyse code.
  • Leverage CI in other practices, such as possibly exploring Feature Branching...
So seven main areas! Obviously this isn't all going to happen overnight but I really hope to achieve all these goals in the near future... It is all just a matter of time and patience I suppose!