Software testing TDD tutorials and videos

RSpec – Behavior-Driven Development for Ruby

Software Testing Magazine — Fri, 09 Sep 2022 06:00:25 +0000

RSpec is an open source Behavior-Driven Development (BDD) ruby package that lets you build a specification alongside your software. BDD is an approach to software development that combines Test-Driven Development (TDD), Domain Driven Design and Acceptance Test-Driven Planning. RSpec helps you do the TDD part of that equation, focusing on the documentation and design aspects of TDD. You start by describing what you want, using #describe to define each method passing the method’s name as the argument. For class method Rspec prefix a “.” to the name, and for instance level Rspec uses a “#” prefix. This is similar to standard Ruby documentation practices. You define the #context to explain the different scenarios in which the method could be executed. Each #context describes the state of the world before execution of the method. You need a context for each execution path through a method. Finally, you specify the behavior with the objective of having only one behavior specified in each example. Given a file named “sample_spec.rb” with: describe "something" do it "does something" do end end When I run `rspec sample_spec.rb -fn` Then the output should contain: something does something RSpec Best Practices * Don’t begin example names with the word “should”. * Use the right matcher: avoid # before with a double negative * Use the “before :all” block carefully * Do not create hundreds of records for a particular spec * Do not over-mock * Test the edge cases * Stop “spec_helper” from being loaded multiple times * [...]

The post RSpec – Behavior-Driven Development for Ruby first appeared on Software Testing Magazine.

Helping Customers to Write Tests

Software Testing Magazine — Thu, 28 Nov 2019 09:46:59 +0000

Agile approaches aims to improve the collaboration between the development team and the end-users or the Product Owner in Scrum. As far as software testing is concerned, it is however deceptive to believe that this could happen without a strong contribution from software testing experts. In a test-driven approach, when developers pick up a user story to work on, the output of this conversation with the customer should include a set of tests that precisely specify what’s required. Customers are usually not software testers, so we must offer them guidance on this process and help them to identify the test scenarios we’ll need to consider (e.g., if they ask for new library members to choose a password when they join, we might ask the customer to consider what should happen if the password they choose is too weak, or what should happen if the password field is left blank, and so on.) Teams that expect customers to go away and write the tests themselves could be waiting a long time. This is a technical skill that takes a long time to master. If you have dedicated testers on your team, this is one area where they can prove very useful, helping the customer to articulate their needs as tests. Source : TDD, Jason Gorman, http://www.codemanship.co.uk/tdd.html

The post Helping Customers to Write Tests first appeared on Software Testing Magazine.

Improving Metrics With Test-Driven Development (TDD)

Software Testing Magazine — Tue, 27 Nov 2018 15:50:17 +0000

There are still many people questioning the value of unit testing, and even more for the Test-Driven Development (TDD) approach. In this article, Krzysztof Jelski shares with us five metrics that should improve with the adoption of this agile practice for software development and testing. Author: Krzysztof Jelski, Pragmatists, https://www.pragmatists.pl/ You’ve already heard of Test-Driven Development (TDD). Finally you get down to trying it out for real. You even manage to convince your whole team to adopt it with you. Now you ask yourself how to find out, whether TDD actually benefits your team. Let me share with you five metrics ideas, which you can monitor while adopting TDD. 1. Time of running and manually testing your application Coding… Deploy…(coffee)… Yup, here it is! Login: test. Password: test. Click. Click. Click. …(page loading)… Click. Typetypetypetype. Click. Checking… oh no! The calculations are wrong! Coding.. … Does that look familiar? With TDD you will need a lot less of that. Most of the time you will get enough confirmation from a passing test and you won’t be urged to run the app. Of course I mean the case of starting from “no/little automated tests”. Though… From what I have seen so far, consistently practiced test-last is a very rare animal. Usually developers lack motivation to add automated tests after the implementation is finished. In other words, even if your team already writes tests, TDD will make them write more and of better quality. Which means reducing the time needed to manually [...]

The post Improving Metrics With Test-Driven Development (TDD) first appeared on Software Testing Magazine.

TDD: Red, Green and What?

Software Testing Magazine — Thu, 28 Jun 2018 15:43:45 +0000

The “refactor” step in Test-Driven Development (TDD) is deceptively simple: you just have to improve the code, without changing what it does, right? And the experts make it look so easy: “Look”, they say, “here’s some duplication, which I will remove by “insert magic incantation here”. But how should you decide which “duplication” to remove first? What happens if you fix the “wrong” smell? And how do you even see that duplication in the first place? Learn the value of Coupling as a practical tool to help plan and manage refactoring. You will explore a smelly codebase using Connascence – an objective approach to discovering and measuring the important Coupling in an application. Video producer: https://www.agileonthebeach.co.uk/

The post TDD: Red, Green and What? first appeared on Software Testing Magazine.

Java Test Driven Development (TDD) with Spring Boot

Software Testing Magazine — Thu, 07 Jun 2018 14:26:54 +0000

This tutorial presents how to do Test-Driven Development (TDD) for a Spring Boot application and how some of the latest Spring Boot annotations and utilities make that easy. Ever wonder how to test a hard problem like caching or write an integration test without making an external API call? Or come across a situation where testing something was so hard that it never got tested? A lot of Java and Spring software developers find themselves in situations where they are unsure of how to write light-weight unit tests for their code. This presentation dives into some tricky real world Java software testing scenarios such as database queries, caching, reactive components, and message brokers. Video producer: http://www.spring.io

The post Java Test Driven Development (TDD) with Spring Boot first appeared on Software Testing Magazine.

Designing Software Testing Experiments

Software Testing Magazine — Mon, 12 Mar 2018 17:02:45 +0000

There is a lot of talk in modern software testing teams about experimentation. Classically an experiment is a very structured series of activities designed to find something out. Sounds a lot like software testing and is in direct alignment with the concepts around Test-Driven Development (TDD), Behavior-Driven Development (BDD) and Acceptance Test-Driven Development (ATDD). This video discusses how to design testing experiments that are valuable and provide the right insights to the right people, at the right time. In this video, you will learn: * What is an experiment? * Why do we experiment? * How are testing and experimentation aligned? * How do we structure software testing experiments? * How we do learn and adjust based on the findings – pass or fail! Video producer: https://cucumber.io/

The post Designing Software Testing Experiments first appeared on Software Testing Magazine.

A Baseline Approach to Software Testing

Software Testing Magazine — Mon, 09 Oct 2017 17:08:39 +0000

Unit testing and Test-Driven-Development (TDD) are an important part of every Agile software testing strategy. One of the issue associated to these techniques is the coupling between the source code and its tests. In his blog post, Tingan Ho presents a testing strategy, called Baseline Testing, that should solve the coupling issues with TDD. The ideas of Tingan Ho are based on the testing strategy of the TypeScript compiler. This blog post starts with some basic information about automated testing and the type of problems that it creates for software developers. One of them is that the validation of the unit test is included in the test code. If the source code changes, then you need to change your testing code. In the Baseline Testing approach, tests record and store all results and match them with a reference baseline, which consists of the previous accepted test results. Baseline Testing does the contrary to TDD as it fits the tests after the source code. However, Tingan Ho writes that his approach allows to be more productive than TDD. His conclusion is that “Baseline Testing is a bold, but very effective strategy. It is bold because it questions an historic sound testing strategy — TDD. It is effective, because with just a press of a button, you have created new test verifications. What took hours and days to refactor with TDD - now only take seconds to do with Baseline Testing.” Read the complete blog post on https://medium.com/@tinganho/baseline-acceptance-driven-development-f39f7010a04

The post A Baseline Approach to Software Testing first appeared on Software Testing Magazine.

Unit Testing Costs and Benefits

Software Testing Magazine — Tue, 10 Mar 2015 17:35:40 +0000

There is always a lot of discussions about the costs and benefits of unit testing. The opposition was exacerbated by the adoption of Test-Driven Development (TDD), a technique that recommends writing unit tests before you write the code. In this blog post, Steven Sanderson discusses unit testing with a costs and benefits perspective. Steven Sanderson gives two reasons for writing his post: the need to understand the reasons that make unit testing worthwhile and the fact that we don’t achieve 100% unit test coverage is not necessarily a bad thing. According to him, there are also two basic reasons to write unit tests: “Unit tests help you to design some code while you’re writing it, and also help to verify that your implementation actually does what you intended it to do.” This lead to the conclusion that “the benefit of unit testing is correlated with the non-obviousness of the code under test.” The post then lists the different costs related to unit tests, both when you write them and you maintain them. Steven Sanderson provides a matrix where you can compare the benefits and the costs of unit tests. Depending on where your code is located, this should help you decide whether or not you should write unit tests. The blog contains a final discussions about the merits of Test-Driven Development and integration testing. Read the complete blog post on http://blog.stevensanderson.com/2009/11/04/selective-unit-testing-costs-and-benefits/

The post Unit Testing Costs and Benefits first appeared on Software Testing Magazine.