This repository aims to share some testing techniques. Keep in mind that the code you will see reflects the final stage, it doesn't guide you through the process of refactoring your code (and test), that's why you should read the exercises beforehand and try it yourself.
You should use this repository as a reference.
- Write the assertion first and work backwards
- Run the test to ensure it fails in the way you expect it to
- Write meaningful tests that are self- explanatory
- Tests should only have one reason to fail
- Triangulate through concrete examples towards general solutions
- Don’t refactor when tests are failing
- Keep your test and model code separate
- Isolate your tests so they run independently
- Organise tests to reflect organisation of model code
- Maintain your tests
It's important that when you develop software for someone you get to talk with the person (or people) who will use the software.
Talk with them to figure out what are the requirements and make sure the language you use in your features are common words known to your clients business, if you can't come up with a name for a specific feature make sure you approach your client and you work together to come up with a meaningful name for that feature, never come up with your own names, the software should adapt to the business not the business to the software.
CRC cards are a brainstorming tool used in the design of object-oriented software.
They were originally proposes by Ward Cunningham and Kent Beck as a teaching tool, but are also popular among expert designers and recommended by extreme programming supporters.
Martin Fowler described them as a viable alternative to UML Sequence Diagram to design the dynamics of object interaction and collaboration.
The card is partitioned into three areas:
- On top of the card, the class name
- On the left, the responsibilities of the class
- On the right, collaborators (other classes) that this class interacts with to fulfill its responsibilities
Test double is a generic term for any object that stands in for a real object during a test - think of "stunt double" in movies.
Class with test-specific implementation (hard-coded responses)
A full implementation for test purposes (e.g. in-memory database)
### Mock
An interface with expectations set for the test (implementation generated at runtime by mocking framework)
A null or dummy object to be used as parameter value when your code doesn't care about.
In the following example we have a Consumer class that receives a stats_client that we don't care
which one is it, as long as it has an #increment method.
class Consumer
def initialize(name, stats_client: NullStatClient.new)
@name = name
@stats_client = stats_client
end
def run
@stats_client.increment(@name)
end
private
class NullStatClient
def increment(key)
end
end
endBug reports and pull requests are welcome on GitHub at https://github.com/Davidslv/tdd-workshop. This project is intended to be a safe, welcoming space for collaboration, and contributors are expected to adhere to the Contributor Covenant code of conduct.