Read the tests, best way to get up to speed with a new codebase

This was a talk I gave at RubyConfAfrica2025. It elaborates on the importance of tests as documentation for the future.

Transcript

1. Read the tests Getting up to speed with new codebases By Patrick Wendo
2. Who am I? > Patrick Wendo > Ruby & Elixir developer ( github.com/W3NDO ) > OSS contributor > Twitch Streamer ( twitch.tv/w3ndo_ )
3. What we will cover ➔ Tests & TDD. ➔ What types of tests exist ➔ How to write tests ➔ How to read tests ➔ What should you take away from this talk?
4. ➔ Tests & TDD. ➔ What types of tests exist ➔ How to write tests ➔ How to read tests ➔ What should you take away from this talk?
5. What are tests? > Guards rails that provide confidence that our code does what we want it to do. > A form of living documentation.
6. Should we use Test Driven Development (TDD)? > Do what makes your team most productive > But also, yes. Source: https://www.linkedin.com/posts/jasonswett_tdd-has-an-unfortu nate-reputation-as-being-activity-7344036407851552769-pui S?utm_source=social_share_send&utm_medium=member_deskt op_web&rcm=ACoAACjWRfQBqoHqXoHElKhBhOCEhsPQacL B1q0
7. Is TDD good? > TDD needs commitment. > I think TDD allows for taking on the baggage early, so that the load is lighter later
8. Ok cool, but why tho? > Software is internally dependent. > We want to be sure that the changes we make in one place don’t break the entire system. > Tests act as an early warning system. > “Testing isn’t just about catching bugs, it is living documentation” ~ David Caixinha, ElixirConfEU 2019 Source: https://www.youtube.com/watch?v=uc5aoM_WDqk
9. ➔ Tests & TDD. ➔ What types of tests exist ➔ How to write tests ➔ How to read tests ➔ What should you take away from this talk?
10. Types of tests > Unit tests > Integration tests > Contract tests > System/E2E tests Source: https://circleci.com/blog/testing-pyramid/
11. Our Demo project > We assume the existence of an auction bidding site. It will have 3 models ( Users, Auction Items and Bids ). > A user can have many auction items and many bids. > An auction item can have many bids, but belongs to one user. > A bid belongs to one auction item and one user.
12. Types of tests: Unit Tests > Tests individual components of the system. > Improves overall reliability of the system > Mock or stub dependencies like database calls in order to focus solely on the logic of the component being tests.
13. Types of tests: Integration Tests > Tests how different units or components of a software application interact with each other.
14. Types of tests: System/E2E Tests > Evaluate the entire workflow of the system. > Typically use tools to simulate interaction with the application’s interface. > In our demo project this would involve testing the application’s ability to create a user, create an auction item, create a bid, close the auction and award the auction item to the highest bidder.
15. Types of tests: Contract Tests > An alternative approach to testing, used mostly with microservices. > It captures the interactions exchanged between services, stores them in a contract and then the contract is verified to be what is expected. > Each service can be tested independently of each other with the contract being generated by the code itself. Source: https://pactflow.io/blog/what-is-contract-testing/
16. Types of tests: Contract Tests Source: https://pactflow.io/blog/what-is-contract-testing/
17. ➔ Tests & TDD. ➔ What types of tests exist ➔ How to write tests ➔ How to read tests ➔ What should you take away from this talk?
18. Writing Tests • Majority of the tests you will write will be unit tests ( If you follow the testing pyramid at least ). As such we will focus on writing unit tests. • What are the key tenets of unit testing? ◦ Tests should be Isolated ◦ Tests should be deterministic ◦ Tests should have a single responsibility ◦ Tests should be self descriptive • There are other tenets, but we will focus on these 4
19. Writing Tests • In the subsequent slides, test A will have a mistake, while test B will correct the mistake • For the purposes of demonstration, we will also be using RSpec as our library.
20. Writing Tests ( Isolated Tests ) Why is this not an isolated test Why is this an isolated test Test A Test B Mocks, Stubbing and Doubles These techniques allow developers to isolate the unit of code being tested by replacing its dependencies with controlled substitutes. Source: https://softwarepatternslexicon.com/patterns-ruby/15/4/
21. Writing Tests ( Deterministic Tests ) Source: https://api.rubyonrails.org/v5.1.7/classes/ActiveSupport/Testing/TimeHelpers.html#method-i-travel_to Test A Test B
22. Writing Tests ( Single Responsibility Tests ) Test A Test B
23. Writing Tests ( Self Descriptive Tests ) Test A Test B
24. Writing Tests The full Gist can be found here > Test guidelines will vary from person to person, team to team. > This is a test sample test guideline by Nathan Long and Yury VeliKanau, both software engineers at GridPoint
25. ➔ Tests & TDD. ➔ What types of tests exist ➔ How to write tests ➔ How to read tests ➔ What should you take away from this talk?
26. Reading Tests > Assume you just got into our auction codebase, and your first task is to update the currency situation. Your supervisor wants you to use Euros as opposed to Dollars for auction item listings. > Where do you start?
27. > Read the docs ( Should always be the first step ) > Understand how your team approaches testing. Read their testing guidelines > Recall that tests are a form of living documentation, so by reading the tests you are in fact reading the docs. Reading Tests
28. > Start reading the tests closest to your task conceptually. That is, if your task is focusing on users, don’t start reading tests focusing on auctions. > Expand the tests you read based on the problem dependencies. ** You should also know that some tests are terribly written and they will not always help you in learning about the codebase. ( Writing *good* tests will help you learn how to spot bad tests ) Reading Tests
29. ➔ Tests & TDD. ➔ What types of tests exist ➔ How to write tests ➔ How to read tests ➔ What should you take away from this talk?
30. 1. TDD is good for code correctness and getting everyone on the same page 2. Tests are crucial guard rails and also living documentation 3. Write tests for future developers, and for your future self. 4. Writing tests makes you better at reading and identifying unconventional tests. 5. It’s never “This is not testable”, but instead, “This is not testable, yet” Key takeaways
31. Useful Links I did not include. • https://www.germanvelasco.com/blog/avoid-test-setup-pollution-and-four-pr oblems-it-creates • https://medium.com/free-code-camp/how-writing-tests-for-your-future-self- will-make-your-tests-better-3311a57e07c4h • https://blogs.rahulrpandya.in/write-tests-that-tells-the-story-33f09d743491 • https://youtu.be/MqC3tudPH6w?si=KFf5pUo-cSuOab8H • https://youtu.be/EZ05e7EMOLM?si=PBQqQQS7QsRHV_Cm • https://youtu.be/TsnWOXgh-Ls?si=nhBnhTW6USLpp1V_
32. Plugs & Shoutouts Here are some cool projects I would recommend you should checkout and contribute to. > Ladybird browser by Andreas Kling ( https://ladybird.org ) > Serenity OS by Andreas Kling ( https://serenityos.org/ ) > Bitcrowd RaG ( https://bitcrowd.net ) > CoRecursive Podcast ( https://corecursive.com/ ) > Ruby Friend App, by Joe Masilloti ( https://rubyfriends.app/ )