How To Start Writing Unit Tests

Unit tests should run quickly and test some in-between logic. In the context of developing a social media application, it's unnecessary to manually navigate a browser, log in, and create a new post just to verify the functionality of a hashtag detection feature. Put that logic in it's own function and unit test it. Then the e2e tests exist, but are slow and run less often, maybe only on a test server when you push your feature branch.
Help support me make more videos: ko-fi.com/meec...
🔗
My Website: www.sammeechwa...
Instagram: / meech_ward
TikTok: / meech.s.ward
X: / meech_ward
Threads: www.threads.ne...
Github: github.com/org...

[@SamMeechWard]

I was caught off guard when recording, because I thought my code worked. It wasn't until I ran the tests that I realized there was an issue. So I did the first thing that came to mind to get the tests passing. I might then go back and refactor my code to make it better, and my tests would tell me if I messed anything up.

[@MartinBarker]

haha, was going to say "perfect example of why Tests can create problems change the code to pass the test and not what is best" and then you put a comment that said that exactly
i would have done a .filter so im just removing keys from a hash not creating a whole new array from a whole new Set object :D

[@gyenabubakar]

@@MartinBarker does filtering perform better than what was done in the video?

[@mickmister]

As long as this is done only once (versus something like a React render method), what's the issue with using a Set? Seems like the shortest way to do this if you're working with an array. Sets are meant to do "uniqueness" for you, so it "just works". Imo this "filter unique values in this array" use case is the main reason why sets exist in js now, because there's no array.unique function.

[@mickmister]

Also to expand on your point, with .filter, you would still be creating a new array, so that part is the same I would say. I'm thinking the test did a great thing by showing the bug, and it was then fixed because of the test failure. Curious why it's bad to fix the code to make the test pass?

[@SpongeBOBat4]

This is excellent way to getting to tests which most people usually skip

[@stevecarter8810]

Preach!
Do this whenever you use the word "should" in your internal dialog. This regexp should match valid filenames => *does* it though? Extract and write a test.

[@ashuzon]

Great tip! That's the reason why I love you man.

[@szmr]

I’m a junior and at work we don’t write tests so I’m trying to figure it out outside of work and this video is quite helpful 👍

[@MrWillooo]

Good for you. Test your own code as much as possible - It makes life much easier when you have to change things

[@Quillraven]

Why don't you write tests at work? I'd raise that to your Senior/Lead because that sounds quite annoying when it comes to bug fixing or analyze other peoples code when you don't even know if their code is verified against certain scenarios/assumptions.

[@JT-vg8wk]

Don’t take this as best practise look at TDD techniques and learn which layer of abstraction is best to test at. Not testing every function in isolation.

[@Robert-pz4wg]

Your manager and company is failing you.

[@szmr]

@@Robert-pz4wg that’s good to know 😅

[@JT-vg8wk]

I strongly urge anyone considering this to think about it before doing what was shown here, you can extract that function for readability but I recommend keeping the test at a higher level e.g entry point of the API or what ever is your main function.
This gives you flexibility to refactor between boundaries without having to update loads of tests. Only write tests like this in isolation if that function is being reused elsewhere or when that entry point is growing legs you could then choose cleaner abstractions not test per function. A repo with a test for every function in isolation would be a massive pain in the behind.

[@bdd740]

Looks great.

[@JanBebendorf]

You forgot to mention that you need to also implement type-checks at the beginning of each function and also test that unless you are running on bun because typescript has no type-safety at all, those types are just nice hints, nothing to depend on.

[@oliverhughes169]

If you're writing a library and the function could be used anywhere, then yes that would be a good idea. Though if it's just a func used inside of your TS code base, I wouldn't recommend testing the types, just let TS do that, that's why you use TS in the first place.

[@JanBebendorf]

@@oliverhughes169 Yes, if strict mode is on and your code never interfaces with anything except your own codebase

[@anirudhdhsinhjadeja8622]

That's actually a useful tip. Btw, could you please tell me how you opened that command window for copilot? I know how to add comments and make it work but giving it instructions is really useful. I don't know how to open that window to give instructions. 😅

[@SamMeechWard]

on a mac, it's cmd + k then i

[@pantherdddjvdgx]

You still need to test the rest. The whole idea is max coverage and not selective coverahe

[@oliverhughes169]

That would be covered ideally in an integration test. The topic of this vid is unit test

[@LeCigareVolant]

Testing? But that's what my users are for 😂

[@IkromAuliaFahdi]

could you share the github? I have struggle when try to create integration unit test

[@tresvecesno7071]

Nice.
One question, I get surprise for the speed of bun: is your video edited not showing the real speed or is that fast?

[@SamMeechWard]

Bun is fast. I also have an expensive computer. But bun is just fast

[@tresvecesno7071]

@@SamMeechWard Thanks!

[@user-gh4lv2ub2j]

I am so happy I don't need to touch TS anymore. Python RULES!

[@mohamadybr]

Is this from a stream, a video, or somewhere else?

[@MaxBertta]

Great tip!!! Thanks for sharing!
What's your theme??

[@SamMeechWard]

night owl

[@Wineblood]

Pure functions ftw

[@Anto-mi5pn]

Is it really necessary to do unit tests where DB and API calls are mocked before doing integration tests where these are not mocked?

[@SamMeechWard]

I would avoid mocking. If you've never done it, try it at some point, but my advice from experience is to avoid mocking

[@SamMeechWard]

Unless you absolutely have to. I write some embedded programs where I really want to do an integration test with a motor or something physical. In that case I mock to run tests a lot of times, then do the integration test with the real motor at the end.

[@Anto-mi5pn]

@@SamMeechWard Damn, that makes a lot of sense. Thank you so much.

[@ShortFilmVD]

There's no good reason not to unit test those things. If you've written a piece of code it should be testable. If you're integrating with an API, it's pretty trivial to get example responses, and if you're using dependency injection, swap in a mock and return those responses to the rest of your code. You'll thank yourself for it later.

[@ShortFilmVD]

I'll also add that having full coverage on your tests, with decent mutation and performance testing gives you massive confidence when updating dependencies and making changes.

[@der.Schtefan]

Stop writing tests the conventional way! Start using ATDD and Cucumber, especially for repetivite stuff that fits in a table, like string processing.

[@folkrav]

I don’t see how they’re orthogonal. I see them more as complementary. BDD/ATDD and unit/integration tests should not be - directly - testing the same concepts at all.

[@PrabhatSingh-8533]

​@@folkrav😮

[@snekface1707]

Wtf I wish I had copilot now 😭

[@johnddonnet5151]

Wtf these tests run instantly

[@Bliss..]

is this copilot x?

[@devonchia5976]

How do we know which section of our codes to unit test ?

[@SamMeechWard]

First step: find pieces of logic that can be meaningfully refactored into pure functions. In 2024, you could probably just ask co pilot to help with that.

[@vikingthedude]

No point testing code that’s calling an external lib, also code that’s declarative-ish such as “mapping” code, schema construction code, etc. best to test complex imperative logic that takes in input and returns output

[@ShortFilmVD]

I say test all of the code that you have written. Your code should be testable, if it's not how can you prove it works? If you're doing TDD you're already covered. Once you get to 100% test coverage, don't stop there, add some performance tests and mutation testing. Well written code is easy to test. If you find some code that isn't, that's a bad sign and you should consider rewriting it.
If you've got good tests, code changes become a lot easier to make, the softer the software the better 😉 you prove to your current self, collaborators, and to your future self that the code does what you think it does. Unit tests are to software what double-entry bookkeeping is to accounting. There's no good reason not to test!

[@PieterWigboldus]

Nice, but i think when you start, begin with a test, and let copilot write your code. You define what it could do, and that is the test, code is less important than the test.
Your coworker can refactor or write the code if you have the test.
If you have only the code, what was expected that it should do?
And then you also do TDD.

[@billyhagood6014]

Why do we put up with js/ts its disgusting

[@tolstoievski4926]

neat

[@darth0s]

🤯

[@Elrinth]

too complicated, and depends on having your test libraries...

[@CrynogarTM]

I see const fetishism

[@alimodz6253]

This is too hard 😢

[@Lukasz7z]

Every day a little more don’t give up

[@incarnateTheGreat]

Reusability.

[@hey_james]

Hipster dev tash strikes again.

[@nikolaikalashnikov4253]

100% *_Cancer_*

[@Kenbomp]

Haha you can't test thenhhtp.requeat you mean.suggest batchthe rrquests in one request.