Write 3X Better Unit Tests using Abstraction | Flutter Unit Testing
Вставка
- Опубліковано 24 сер 2019
- In this tutorial we go over how abstraction helps you write better, maintainable and 100% reliable unit tests in Flutter. This is the second video in the abstraction series.
📚📗 Written Tutorial: www.filledstacks.com/post/bet...
👨💻 Starter Code: firebasestorage.googleapis.co... - Наука та технологія
Amazing! The more abstraction you have, the fewer headaches you suffer!
Agreed 👌👌
That's why we are learning Clean Architecture + TDD
Thanks for sharing your knowledge! Looking forward to more videos, especially around TDD and unit testing.
Thank you Jeff. I appreciate the feedback, I'm planning some TDD videos. I'll be releasing them once I've compiled everything around it for Flutter.
A full tutorial would be great! You make the most practical and useful flutter videos I've seen so far 👏
Thank you 😊 the TDD turned out to be quite a hand full so I kind of shoved it to the side when things got a bit busier my side. I'll keep it on the list, i would like to cover it in regards to Flutter. Thank you for the feedback.
Another helpful video for rapidly learning Dart/Flutter/Testing. Tx!
😊 thanks for watching.
Absolutely insane. I'd really enjoy a full TDD tutorial. Kee going!
Thanks 😊 I'll see where I can squeeze in a TDD series.
This video is GOLD! This together with "Flutter Provider V3 Architecture | ProxyProvider for Dependency Injection" is exactly what I was looking for!
Would be awesome if you could create a video with TDD and Provider V3 and also talk about the folder/file structure you use to organize your code.
Thanks a lot for sharing!
Awesome 🙌 I'm happy to hear that. File structure is different per project. But it follows mostly the architecture videos you see on my channel. I was planning on a TDD set of videos but it's quite a bit to cover. I'm looking for better ways to get my points across then I'll make it.
Quality content
Thank you
Great work! Please do a full tutorial on Flutter TDD :)
Thank you! It's on the list, just want to gauge how many want to see it and I'll decide when to get it out.
Please I do want it.
@@FilledStacks can't wait
@@FilledStacks Really looking forward to
Yes please, I know Reso Coder has a TDD course based on Bloc but having one based on Provider would be amazing as it would make crystal clear how to test apps with this architecture with a good understanding!
More in depth TDD + Unit Testing please. Thanks a lot for your great work!!!
I was planning on it but it's not a priority now. I'll still be making it at some point.
@@FilledStacks It's okay.. I really appreciate your work.. You're tremendously helping a lot of developers like me to be a better programmer.. Thanks so much
@@oliverbytes Thank you for the awesome feedback. I'm very happy to hear that my work is making an impact in real world code bases
Awesome tutorial. I want to learn more about this topic. Do you have any tips for Solo Developers? It's difficult to start with TDD when you're freelancing or working on a startup.
Thank you 😊 Yes, I am a freelance developer and working on some of my own small business ideas (don't like the term startup). I apply TDD sparingly, meaning only where required. I don't do it for all part of my app, if something has a predefined outcome that has to be the same everytime like a parser, formatter, calculator, etc it's actually much faster to write the tests for the functionality first then confirm everything is working. It's faster than starting up the app, putting in some values and then testing the one new change, if you know what I mean. When it comes to unit testing the interaction of the services in my app and database implementations I don't do that for small projects or freelance projects in a TDD style. I do that after since requirements change very often and will cause tests to keep changing. If the spec is strict, input = altered output then i do TDD. Otherwise not.
If you maintain your abstractions properly and have fake prop versions of it , ready , so that you can test your programs , faster , i think mocking everywhere might be unnecessary and you can just use the props and minimal mocks to still maintain the unit tests, this is particularly useful if you're mocks start becoming more complex , depending on the business logic , and will help you make your tests more readable and also save you time and reduce complexity , Awesome video btw !
Agreed! The reason why I use general mocks still is because it'll allow me to not have to define every function and "just make it pass". It also allows me to change what's returned per function call for every unit test. In addition to allow me to test interactions / calls / lack of calls.
But fake data only for strict unit tests is also something I've done before. Much easier to maintain as well and easier to understand.
@@FilledStacks ah yes indeed , Awesome :D ,
Have a great day !
All you’re videos are amazing
Good luck to you :D
May you get 100x more popular on UA-cam
Thnx for the content
@@teitoklien Thank yoooou! Much appreciated. I hope that I can get maybe just a little more popular. It'll only improve the amount of knowledge I have access too which I can then share back with the community.
Thanks for watching, I really appreciate you commenting and taking in this information.
Hello, great video. I have a question, what if I need to verify a method call inside the same PostService class ?
Thank you. I usually add one test to confirm the result or state change of that function. The rest of the tests is written directly for that method call.
If the method isn't called anymorw the result / state will be different. If that method is changed some of it's unit tests should fail. covered from both ends.
I'd appreciate any input you have on TDD or testing in general. learning OOP, testing seems like a level of complexity I can't even wrap my head around yet.
Writing meaningful tests seems like an art that will take a ton of time and practice to learn, and having a suspect/bug-prone app in the meantime. Most of the examples I've found for flutter tests seem trivial, like "does this widget return one widget". Not sure why that would be useful development time spent to write.
I agree. There's a lot of practice associated with it, the same as with software engineering in general. But there are some guidelines and forms of practice you can do that will make it easier. I'll compile all my knowledge around it and produce one or two videos on it. Thanks for letting me know.
Great tutorial!, can you make a video explaining how to setup this abstractions and unit testing with BloC pattern ???
Hi thanks for the feedback. I don't use the BLoC pattern so I won't be doing a video on it. ResoCoder released a video today about TDD using the Clean architecture. He uses bloc for his state management so I assume he'll cover the unit testing for Bloc as well since he's doing TDD using it.
@@FilledStacks Thank you.
Excellent demo, any reason you didn’t make mockito a dev dependency?
I forgot 😅 i think it's dev in the written tutorial.
If using Firestore as the storage solution, how would you do a unit test for the following scenario.
Have a TODO App and want to change a Task status to done. So you basically would have a "todo_service", or "storage_service" with a method like this
Future toggleTask(Task task) {
var ref = _db.collection('tasks').document(task.id);
ref.updateData({'done': !task.done};
}
At this point, the task is already updated, but without actually doing task.done = !task.done directly on the task, the update depends on Firestore. You could spin up the firestore-emulator I guess, but I wonder how would you solve that case.
Thanks!
Hi there, I would "trust firebase 100%" meaning not write any unit tests for it since that's not any of my code. I'm just making use of their code. The furhtest I would go is to make sure the toggleTask is called with the correct value and that it doesn't throw any exceptions and that it completes. If you're testing the third party dependencies it's not a unit test anymore, it's more along the lines of an integration test. I'd mock the service and test how my code responds given a crash, or the correct/wrong values/null values being passed in. I wouldn't test firestore itself. They have their own unit tests.
Do a full tutorial on Flutter TDD :)
I don't follow TDD in production so I don't want to be a hypocrite :) I might just do one on general unit testing.
Please make a full test tutorial,
And i want to ask you about your opinion in "Hive" package as a replacement for shared preference they claimed to be much faster and efficient
I haven't been doing a lot of unit testing recently. i try to only make videos of things I'm actively using. i do basic testing to confirm behavior in the app but not full coverage. resocoder has a full TDD course which should give you the idea of how to write tests.
And relating to Hive. i haven't used it. I'll maybe check it out and see how it is to work with.
I watch couple videos of his tutorial, but i found his approach overwhelming and time consuming that's why like your way of doing things.
Thanks for your time any way♥️
@@berosolo866 Aaaaah, I see. It would have been a bit easier if he taught the idea behind unit testing first and then gotten into the implementation. It's definitely something I want to teach as well, so it's on the list. Just not for anytime soon. Next series I want to make is a complete guide on firebase integration, implementation patterns and overall project structure and setup for the best experience.
It would be very helpful to have also some example on how you would implement your architecture for Create/Update/Delete logic, some data modification, not just getting data, as well as unit tests for those.. Thanks!
I've seen that request a few times. The video won't be much different. I'll add a function on to service and perform a delete in it. Usually i use my api request to remove on the server then i remove from the list locally and refresh the results. What do you mean by your crud. All my stuff happens on the backend. It's just plain api calls.
@@FilledStacks Right, everything is api calls, but if you look at my other comment, the example about a task status toggle, I'm not exactly sure how to test something like this:
- viewmodel.toggleTask(task)
- (api) firestore.instance.collection('mytasks').document.('thetask').update({'done': !task.done})
- unit test should verify taskbefore.done == !taskaftere.done
That's kind of an oversimplification.. in your example, imagine you could mark a post as read, just adding that use case and the unit test would be similar.
Thoughts?
@@dc5 Aaah, well that would depend on your level of abstraction. You should be trusting the thirdparty is completely unit tested 100%. So for instance if you call update on firestore to update, you should assume it's updating. The level you have to concern yourself with testing is how your code reacts to that update call. So abstract the static firestore instance into an interaced implementation so that you can return mock values to test how your code responds. I don't test third party calls, only how my app responds to it. I don't know if that answers your question. Working on an abstract manner, "just calling update on the service" is how I like to work. The implementation I leave to later, sometimes even as the last step since you can build your entire app very fast using fake data etc. Therefore you test what your code does given certain results from the service, not what results those service gives (if it's thirdparty). If it's all your code then you should test it.
@@FilledStacks You're absolutely right, and you're already doing this in your code, after looking more into it I saw it, you basically mock what the api would return and call verify on the storageService to ensure it was called, and as you mentioned, you assume, given that's external, that it was successful. Thanks again, really appreciate your time and help!
@@dc5 I'm happy to help. Sometimes it's a bit difficult to answer given that I don't have all the context of your situation or question. But I'm always happy to hear that you gain some kind of insights from the answer.
Wouldn't it be possible to create a mock class without defining the interfaces? For example something like this:
`class MockStorageService extends Mock implements LocalStorageService {}`
yes, that would be possible.
for those who had flutter related testing issue to make the test at 2:36 pass according to 11 May 2020 you need to update your flutter version to the latest stable channel and then re-run the test then everything will run fine
Thanks for the update @Freelance &Code. I appreciate it.
@@FilledStacks Thank you Dane for all your efforts
@@mohabmagdy4155 It's my pleasure. I learn more and more as I make these videos.
Please create a complete TDD project.
My latest unit test videos shows my TDD process that I follow.