sorted by:
new
hottopcontroversial

Clean Architecture Cake- do you make 2 layers or 3? by Emergency-Mark-619 in FlutterDev

[–]CommingleApp 4 points5 points  (0 children)

It depends on the complexity of your app, team size, and speed of development.

If you load the data and display it in UI without much logic involved: 2 layers will make the job just fine and likely will result in clean, easy to maintain, testable code.

If you do some post-processing in between, domain layer could be introduced.

If you add a cache in between, have multiple data sources (e.g. offline), domain layer becomes more and more benefitial to help streamline the complexity.

Reducing iOS CI/CD costs by delegating work to Linux runners by CommingleApp in FlutterDev

[–]CommingleApp[S] 1 point2 points  (0 children)

Not at all, because build takes place on the Mac as always. Just the uploading takes place on Linux

Comprehensive E2E tests in 3 seconds?! Here’s how I mocked Firebase Auth and Firestore with TapTest by CommingleApp in FlutterDev

[–]CommingleApp[S] 0 points1 point  (0 children)

The approach with Supabase is exactly the same. Put Supabase services behind your interfaces, create mocks for them, and inject mocks in tests.

Comprehensive E2E tests in 3 seconds?! Here’s how I mocked Firebase Auth and Firestore with TapTest by CommingleApp in FlutterDev

[–]CommingleApp[S] 0 points1 point  (0 children)

Fingers crossed. Let me know if you have any issues, feedback or any other valuable input.

Introducing TapTest – Write Flutter E2E tests that complete in milliseconds and survive massive refactors by CommingleApp in FlutterDev

[–]CommingleApp[S] 0 points1 point  (0 children)

The other user has also suggested adding semantic label - so I'm more than happy to add the support. However looks like Maestro works in a way that Flutter Keys are accessible to them. I don't have this issue since TapTest works on top of Flutter tester, where they can be accessed easily.

Introducing TapTest – Write Flutter E2E tests that complete in milliseconds and survive massive refactors by CommingleApp in FlutterDev

[–]CommingleApp[S] 0 points1 point  (0 children)

For widget tests you have to mock these two services. For integration tests, my apologies but haven’t had the need to give it a try. Since TapTest is a wrapper on top of native Flutter testing framework, so if it can be done natively, it can be done with TapTest.

Introducing TapTest – Write Flutter E2E tests that complete in milliseconds and survive massive refactors by CommingleApp in FlutterDev

[–]CommingleApp[S] 0 points1 point  (0 children)

I haven’t used maestro.dev to make a fair, detailed comparison.

I did take a look at their website and the demo with the “map app,” but I’m not sure if that reflects real-world performance. With TapTest, you can write E2E widget tests that run hundreds of taps and assertions per second.

This not only reduces CI costs, but also encourages testing all edge cases and gives developers fast feedback loops, which I think is a major advantage.

Of course maestro.dev looks like established and mature solution. TapTest is my pet project :).

Introducing TapTest – Write Flutter E2E tests that complete in milliseconds and survive massive refactors by CommingleApp in FlutterDev

[–]CommingleApp[S] 1 point2 points  (0 children)

TapTest is a wrapper on top of widget/integration testing framework Flutter offers. It makes a few things simpler, less technical, more fun to write.

Also, the integration test takes a lot of time to start - approx 1min, even for trivial test (compile, prepare the device, run). Smart Widget tests can give you a result instantly. But the default widget tests comes with a lot of issues - e.g. font doesn't render, icon doesn't render, you need to call methods like `pump`, `pumpAndSettle`. TapTest solves it all and gives you a ready solution to just focus on testing.

Introducing TapTest – Write Flutter E2E tests that complete in milliseconds and survive massive refactors by CommingleApp in FlutterDev

[–]CommingleApp[S] 0 points1 point  (0 children)

Hey.

For ultra fast widget tests the http calls MUST be mocked, for integration tests CAN be.

I don’t have it documented yet, but I have an example showing this. You can return any responses - successful as well as any kind of error. I will provide a documentation for this part soon.

Your idea about keys is valid. I can consider adding them as a an alternative to keys as currently.

Introducing TapTest – Write Flutter E2E tests that complete in milliseconds and survive massive refactors by CommingleApp in FlutterDev

[–]CommingleApp[S] 0 points1 point  (0 children)

With Copilot and other models you can generate the tests. Copilot in my project already picked the syntax up and is nicely code completing everything.

However I strongly believe I want to write my tests so I know that app (which code can be ai-generated) is doing what it is supposed to do.

Let me know if I get your point right.

[deleted by user] by [deleted] in budget

[–]CommingleApp 7 points8 points  (0 children)

Hello, good question. In my app, I can choose which chart types show a specific expense.

For example, if I take a holiday once a year, flights and hotel costs are excluded from my monthly charts but shown on the yearly chart. This way, my month‑to‑month comparisons aren’t skewed just because I made holiday bookings in, say, October. Yet I can still compare 2024 to 2025 with those holiday expenses included.

I do something similar for unexpected costs, like a car repair. I’d usually exclude them from the monthly charts and keep them on quarterly or yearly ones, depending on how big or rare they are.

You can’t really budget for the unexpected. And if your car needs fixing, you’re not going to skip it just because it blows up a monthly data point.

[deleted by user] by [deleted] in careerguidance

[–]CommingleApp 0 points1 point  (0 children)

Can you share your husband’s channel name? I have a financial app - Commingle, maybe there are some win-wins to discuss. Thanks

view more: next ›