I need to start writing test, any tips?

My projects have been growing a lot recently and the have been growing in complexity. I feel that I need to start writing test, where should I start?

Comments

[Ryan Latta]

My advice to get comfortable with testing would be to do this:

Pick a really small project that you understand pretty well. I personally use a vending machine as a project I rebuild often.

With that simple project in mind, set to rebuilding it using what you want to try with testing. That way you'll have a way to compare your results.

If you are going to try TDD (And I very much hope you do) I will further recommend this to start even though it sounds ridiculous.

1. Start with a test file
2. Write a test describing what you intend for some small part of your project to do.
3. Watch it fail
4. Put just enough code in the same file to make it pass
5. Refactor - Only by move and extract.

You'll wind up doing TDD in one file at first, but it'll get you moving and a feel for the process. Do this for 45 minutes - 2 hours. Stop and look at the code you wrote, the tests you wrote, and see what you think of the results.

[wolfiton]

Really good advice @RyanLatta, to start on the familiar ground first before diving deeper into tests

[Fulton Browne]

great advice, I have some projects I could do that on.

[wolfiton]

On what programming language would you like to start learning about TDD, end-to-end testing or integration tests?

Because I saw on your GitHub that you have a lot of languages there and frameworks:

• kotlin
• javascript
• ruby on rails
• python

Or are you interested in learning about testing in general?

[Fulton Browne]

I would say js and Kotlin mostly, but general stuff would be great too.

[wolfiton]

Google is always the first step to get more info, try this:

google.com/search?client=ubuntu&hs...

This URL is for javascript testing.

This URL is for kotlin

google.com/search?client=ubuntu&hs...

Also, I don't know, if I am allowed to say this(If not, please delete this post)

But I am planning on releasing my own course site platform in the next months. That will have real-world examples with tests.

Also to get a feeling of how I teach, read my posts on Absinthe.

The first part is here dev.to/wolfiton/absinthe-journey-w...

[Fulton Browne]

thanks, I will take a look

[wolfiton]

You are welcome, I hope it helps.

[Max Ong Zong Bao]

Find a local coding dojo to practice code kata by pair programming with another developer. If you are unable to do it you can use Codewars and crack open a book like Pragmatic Programer to help you get started.

Do note that by learning to write test cases you can cross-train someone from a different language due to the concepts of testing is almost the same across languages.

[Fulton Browne]

Thanks I really appreciate the advice.

[Ghost]

First of all, be clear of one simple fact

TDD != testing

knowing that try TDD and if you don't like it, don't feel bad about that, that doesn't make you a bad coder, evil or "unproffesional" as the zealot Bob Martin may lead to believe. The only important thing is test well and test thoroughly, untested code is unfinished code and not because you say it run someone else or even yourself should believe it, you have to test it to prove it.

Untested code is not even bad code, bad code run, untested code may or may not run, who knows?

[Ghost]

People always say to chop functions as small as possible because they are easier to understand, that never convence me, if doesn't lead to duplication I prefer a longer function where I can see everythin in one glance; for me readability is not a good argument to chop functions, testing is, you do want to chop your functions not to make them readable but to make testing easier, you really want to avoid functions with many possible scenarios because testing them will be a pain, if a piece of code could have 4 testable scenarios and the next piece 4 more, you have 2 choices: put them in a single function and now test 19 possible scenarios plus a test for the whole or chop them in 2 functions and test just 4 + 4 scenarios plus their "handler" test, complexity doesn't add, multiply.

Of course this is an oversimplification but I hope you get the idea.

That, to me is the big deal, and I don't like to write my tests firsti but what I do take from TDD is coding with testing in mind, you'll probably write more code to test than the running code itself and for me testing take longer than the actual running code, so help yourself and code to make the testing easy and simple. Think testing as documentation, if you want to know what something does, should be clear by looking at the tests.

PS: I hate testing, to me is the most boring part, I really hate it, but avoid it is much, much, and I can't emphasize enough, much worse.

[Jean-Michel 🕵🏻‍♂️ Fayard]

the fastest way is to do pair programming with someone that understands test driven development and ask tons of questions

[Paweł Kowalski]

Start by writing e2e tests (from user perspective) and go down the stack if you need to. That way you will at least know that your stuff is working and when it breaks. :)