วีดีโอ

Nope. You can check the "mocked_backend" package's example for reference and the code of the package itself for inspiration for the implementation.

Faking a dio implementation does not allow you to cover other interceptors or validate (de-)serialization logic. Such an implementation is too specific and coupled with the project, which lowers its reusability. Check the "mocked_backend" package on pub.dev. It's a universal implementation of the interceptor approach that you can use in any project with minimal configuration.

Вітаю! 👋 Напишіть мені в твітер або лінкедін.

Thank you 😊

Дякую 🙂

unfortunately, no

Thanks! If I understood correctly, you want to have E2E golden tests, i.e., golden tests in a real environment. Unfortunately, I'm unaware of how to make the test both golden and integration. Such tests may always fail because of time and notifications in the status bar, and this unpredictability makes it difficult to create proper golden testing. Most platforms for integration testing allow you to do a screen recording. In the tests, you can validate that the user can interact with all controls and see all the important information. If a test fails, you can look at the recording to find out why. I'd advocate for this approach.

Дякую 🙂

I used the "Presentation Buddy" plugin - marketplace.visualstudio.com/items?itemName=mauricedebeijer.presentation-buddy

Would you share the project on GitHub so that I can look?

@@olexale I just create the new Flutter project and when i run step "flutter pub run build_runner watch --delete-conflicting-outputs" it's not render counter file in test

@@nhuyphanmai3657 have you added build_runner and bdd_widget_test to the dev_dependencies?

@@olexale Yes, I have

@@nhuyphanmai3657 would you share the project on GitHub?

Oh, that's great! I truly look forward to it 🙂

All things that you had to replace with mocks will not be tested. That would be platform-specific things (camera, GPS, biometric, etc) as they just don't exist outside of the platform and so are not available in unit/widget tests.

Not really. Indeed you may cover many things in the app with BDD tests, but unit tests might be in hand when you're dealing with libraries or non-UI things that you want to share between different projects/apps. For example, obviously, bdd_widget_test itself is covered with unit tests. 🙂

Sure. What's up?

Hi! Sorry, I don't use flutter gherkin on my projects. Did you know may use this package for integration tests as well? Here is the link for documentation - github.com/olexale/bdd_widget_test#how-to-write-integration-tests

did you get?

No idea 😅 I'm making videos only when I have something to say. Some folks asked me how to deal with network queries in BDD tests, so I think that might be the next topic for this series. If you're using BDD with Flutter and struggling with any problem - feel free to reach me and maybe I'll record a video about that 🙂

Don't be. It's hard to start testing your code when you're the only mobile developer on the project as you'll need to find answers to so many non-trivial questions (like where to start at all, how to share code between tests, what to test, etc.). It's even harder when you have a team that believes that testing just slows down the development without giving anything in return. In fact, that was the reason I've created this BDD plugin. BDD itself is a great technique but it requires the team's collaboration. At the same time, Gherkin gives answers to most of the mentioned questions: - where to start? - create a feature file and implement "the app is running" step. - how to share code between tests? - re-use steps. - what to test? - just describe what the app should do. Using this approach my projects have more than 90% code coverage and zero discussions on the "why we're testing?" topic. I hope you'll give it a try 🙂

@@olexale I'll definitely give it a try when I get the chance

Nevermind, I think I've found why

Hi! If you're talking about tests - ResoCoder registered AuthBloc in get_it via injection (you may see generated injection.iconfig.dart file), and I configure injections in injection_helper.dart file. You may watch ResoCoder's DDD videos (at least the beginning) - he described everything really well there.

@@olexale Yeah I found out that he uses a condition inside the generated injection file to register certain dependencies only if it's a test environment.

@@olexale Btw I have a question, is it possible to test if a Dialog is open using bdd_widget_test? for some reason I have a pumpAndSettle time out error whenever I try to test if a Dialog is open.

Most probably that’s because you’re using platform-specific dialogs. In order to work around that you may create a DialogService or DialogHelper class that will abstract away platform-specific details, and use Mockito to set its behavior in tests.

still arcore sucks bro i just try to create measure app in flutter with ar in ArKit i completed demo app but in arcore i can't because of their limited library

Using marketplace.visualstudio.com/items?itemName=pflannery.vscode-versionlens extension.

Hi! I didn't face any problems with this plugin as it's generating almost the same code I write by myself. BDD approach is all about the real user's interaction with the UI, but at the same time, I use this approach for the development, hence widget tests are a perfect match to have fast development cycles (create a failing test, make it pass, refactor) and getting human-readable tests to validate with the team. While flutter_driver is still beneficial native stuff is too slow to drive the development, it's more about regression testing for the app builds.

@@olexale I agree. So basically what I asked was we still can't do integration testing with this? Which I guess the answer was no. I did a lot of TDD I do solo work all the time and am new to BDD. trying to look at some good content. Figuring it out if it does worth doing it in flutter. Good video ✌️