Tommy Rogers 48cf4595b3 finished FizzBuzz | 6 gadus atpakaļ | |
---|---|---|
FizzBuzz.class | 6 gadus atpakaļ | |
FizzBuzz.ctxt | 6 gadus atpakaļ | |
FizzBuzz.java | 6 gadus atpakaļ | |
FizzBuzzTest.class | 6 gadus atpakaļ | |
FizzBuzzTest.ctxt | 6 gadus atpakaļ | |
FizzBuzzTest.java | 6 gadus atpakaļ | |
README.MD | 6 gadus atpakaļ | |
package.bluej | 6 gadus atpakaļ |
Test Driven Development, or TDD, is a method for approaching a problem not through the implementation of the solution, but rather, through the expectations of a working solution. What that means is, instead of trying to write the code that solves the problem, you first define what the working code will do when it works, and then you write the implementation to make it work.
A classic programming problem is FizzBuzz. It is considered the Stairway to Heaven of programming because there are so many different ways to play it and everyone plays it.
The goal of FizzBuzz is to build a program that can take a number:
Let's approach solving this problem from a TDD approach. That means that we don't care about "how", but rather, we care about "what". What should the program do if it works correctly, not how it does it. We are going to write our expectations first, then our implementation.
Before we look at the RSpec syntax, let's just express our tests in plain English (also sometimes referred to as "pseudo-code").
We don't care how that #fizzbuzz
method works, nor how it's defined, we are just stating our expectations. And we're doing that first. When coding, it's important to have a target to shoot for; by writing your test first and stating your expectations of your code, you know your goal. You get to use your entire brain to think about just your goals, not how you'll get there, which adds clarity and focus to the problem.
The competent programmer is fully aware of the strictly limited size of his own skull; therefore he approaches the programming task in full humility.
— Edsger W. Dijkstra
Test-Driven Development allows us to fully utilize our mental capacity to clearly state the problem we're solving and then to 100% focus on implementing a solution. When you are just coding, you're actually focusing on stating the problem and the solution at the same time. You are thereby splitting your thinking in two, making you less effective at both.
It's the exact same reason you make a todo list. Also testing is not for present you, it's for future you.
— Joe M Burgess
Given a number, your method should return a string: