Tag Archives: Test-driven development

Test-Driven Java Development

5 Replies

7429OS_Test-Driven Java DevelopmentI’m happy to announce that the Test-Driven Java Development book wrote by Alex Garcia and me has just been published by Packt Publishing. It was a long, demanding, but very rewarding journey that resulted in a very comprehensive hands-on material for all Java developers interested in learning or improving their TDD skills.

If you liked my articles on this subject I am sure that you’ll find this book very useful. It contains extensive tutorials, guidelines and exercises for all Java developers eager to learn how to successfully apply TDD practices.

Writing a blog like this requires a lot of time. By purchasing a copy of the book you will not only get a valuable material but also allow me to continue writing new articles. Posts in this blog are only a fraction of what you will find in the book.

You can download a sample or purchase your own copy directly from Packt or Amazon.

Advertisement

Developing Front-End Microservices With Polymer Web Components And Test-Driven Development (Part 3/5): The Second Component

Leave a reply

In the previous article we finished one Polymer Web Component. It contained a form that could be used to add, update and remove books by sending HTTP requests to the back-end server. We also explored few different ways to interact with the component from outside by calling its functions.

In this article we’ll create the second component that will be used to list all the books and send custom events to open an existing or a new book. Those events will not be sent directly to the component we built earlier but to the document the component will reside on. We’ll get to that part in time…

Continue reading →

Developing Front-End Microservices With Polymer Web Components And Test-Driven Development (Part 2/5): Polishing The First Component

Leave a reply

book-form-scIn the previous article we created our first Polymer Web Component using Test-Driven Development approach. While all the specifications we wrote were implemented, there are still few things we should do to polish this component. The tc-book-form currently has the form with all the input fields required by the back-end. It also has buttons to add or update and delete a book. Those buttons are calling iron-ajax Polymer element that sends requests to the back-end. Both front-end (in form of Web Component) and back-end are developed as a single microservice.

The next task in front of us is to polish the component. Later on in this series we’ll create another component that will list all books. We’ll also develop the code that will enable us to establish communication between those two components. Once we’re done with both, we’ll explore ways to integrate the microservices we developed into a separate Web Application.

Continue reading →

Developing Front-End Microservices With Polymer Web Components And Test-Driven Development (Part 1/5): The First Component

10 Replies

In this article series we’ll go through Web Components development in context of microservices. We’ll use Polymer as the library that will help us out. The objective is to create a microservice that will handle full functionality. The service will contain not only back-end API (as is the case with most microservices) but also front-end in form of Web Components. Later on, when the time comes to use the service we’re creating, we’ll simply import Web Components. That is quite a different approach than what you might be used to. We won’t create a Web Application that calls APIs handled by microservices. We’ll import parts of the front-end from microservices. Our objective is to have a microservice that contains everything; from front-end to back-end. Please refer to the Including Front-End Web Components Into Microservices article for more information that lead to this decision.

I am a huge fan of Test-Driven Development so we’ll write all the code using test first approach. We’ll write a test, run all tests and confirm that the last one fails, write implementation, run all tests and confirm that all passed. Tests will act as executable specifications. We’ll use them to define what should be implemented. If you are new to TDD and the concept of executable documentation, please read the article Tests As Documentation.

Continue reading →

JavaScript Tutorial Through Katas: Mars Rover

1 Reply

A programming kata is an exercise which helps a programmer hone his skills through practice and repetition.

The article assumes that the reader is familiar with the basic usage of JavaScript and Jasmine asserts and knows how to run them from his favorite IDE (mine is WebStorm or IntelliJ IDEA).

Tests that prove that the solution is correct are displayed below. Recommended way to solve this kata is to write the implementation for the first test, confirm that it passes and move to the next. Once all of the tests pass, the kata can be considered solved.
Continue reading →

Test-Driven Development (TDD)

8 Replies

What is Test-Driven Development (TDD)?

large__8282043567Test-Driven Development is a process that relies on the repetition of very short development cycle. It is based on the test-first concept of Extreme Programming (XP) that encourages simple design with high level of confidence.

The procedure of doing TDD is following:

  1. Write a test
  2. Run all tests
  3. Write the implementation code
  4. Run all tests
  5. Refactor
    Continue reading →

Scala Test-Driven Development (TDD): Unit Testing File Operations with Specs2 and Mockito

Leave a reply

In this article we’ll go through the exercise of writing a method that will write string content to the specified file. There will be an option to specify whether we should overwrite an existing file. In addition, directories should be created if they do not already exist.

Programming language is Scala and testing framework that will be used is Specs2. In the spirit of unit testing, instead of interactions with the file system we’ll use mocks with Mockito (already included in Specs2). All the code will be done using Test-Driven Development (TDD).

This article is based on an existing code done for the open source application BDD Assistant located in the TechnologyConversationsBdd repository.

Let’s get started.
Continue reading →

BDD Assistant: It’s alive and cries for help

6 Replies

tutorialStoryOperationsI’ve been working with BDD for years and felt that it needed an application that would facilitate the Behaviour-driven development work-flow. It would need to be made in a away that anyone can use it. By anyone I mean people with or without technical skills. Coders, testers, analysts, managers, business, etc. In that spirit, I started working on BDD Assistant. It is an open source application that can be used to create, manage and run BDD stories.

Now I feel that it is finally ready to go public. The application is far from being finished but there is enough done for the community to see what it’s all about. More information can be found in the BDD Assistant site. Latest release can be downloaded from our GitHub repo. Live demo (with some features disabled due to hosting limitations) can be seen from the BDD Assistant demo.
Continue reading →

Continuous Delivery: Unit Tests

4 Replies

This article is part of the Continuous Integration, Delivery and Deployment series.

In the previous article we explored static analysis as one of the first steps in Continuous Delivery. Our journey will continue with unit tests.

Unit Tests

tddBestPracticesAllTestsPassUnit tests are probably the most important part of Continuous Delivery. While unit tests cannot substitute integration and functional tests, they are very easy to write and should be very fast to execute. As any other type of tests, each unit test should be independent of each other. What differentiates unit from other types of tests (integration, functional) is the scope. Each unit test should verify only a single unit of code (method, class, etc). Main benefit of unit tests are that they can find problems early due to their speed of execution. When ease of writing is combined with very short execution time it is no wonder that unit test often represent biggest part of automated tests.
Continue reading →

Tests as documentation

2 Replies

origin_2389320345Documentation needs to be comprehensive, always up-to-date and accessible. By comprehensive I mean that it must cover all important areas of the code as well as all functions of the application. While importance of documentation is obvious to most, many struggle without success to have it accurate and up-to-date. Response to “poor” documentation is often assignment of more resources and more time. More often than not, documentation is created for wrong reasons.

Continue reading →