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

5 ай бұрын

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

5 ай бұрын

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

@mickmister

5 ай бұрын

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

5 ай бұрын

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?

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

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.

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

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

5 ай бұрын

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

@Quillraven

5 ай бұрын

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

4 ай бұрын

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

4 ай бұрын

Your manager and company is failing you.

@szmr

4 ай бұрын

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

Looks great.

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

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.

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

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

5 ай бұрын

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

5 ай бұрын

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

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

6 ай бұрын

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

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

Wtf these tests run instantly

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

@SamMeechWard

6 ай бұрын

night owl

Pure functions ftw

is this copilot x?

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

6 ай бұрын

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

@tresvecesno7071

6 ай бұрын

@@SamMeechWard Thanks!

Wtf I wish I had copilot now 😭

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

6 ай бұрын

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

6 ай бұрын

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

6 ай бұрын

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

@ShortFilmVD

5 ай бұрын

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

5 ай бұрын

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.

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

@oliverhughes169

5 ай бұрын

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

neat

🤯

Why do we put up with js/ts its disgusting

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

@SamMeechWard

6 ай бұрын

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

5 ай бұрын

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

5 ай бұрын

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!

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

@folkrav

6 ай бұрын

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

3 ай бұрын

​@@folkrav😮

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

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.

This is too hard 😢

@Lukasz7z

5 ай бұрын

Every day a little more don’t give up

I see const fetishism

Reusability.

Hipster dev tash strikes again.

100% *_Cancer_*

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