When doing end-to-end testing for Flutter, I find it very inconvenient to debug them. For example, for an e2e test that taps, drags, and asserts a ton of things, when it fails, I cannot know easily what indeed causes the failure. It may be caused by misbehavior that happens 10 steps ago.
Thus, I hope I can have the well-known time traveling functionality for Flutter tests (or, action logs, or screenshots for every step). In other words, with a button tap I can see "what did the UI look like when that button was tapped 50 steps ago?" Then I can go through the history and easily spot what goes wrong.
Is it possible to implement it? Can I integrate it into integration_test-based tests or do I have to create a brand new framework?
Here it goes: https://github.com/fzyzcjy/flutter_convenient_test - Write and debug tests easily, with full action history, time travel, screenshots, rapid re-execution, video records, interactivity, isolation and more. (With a video demo showing GUI: https://github.com/fzyzcjy/flutter_convenient_test#-quick-demo)
The implementation can be seen from the code. Shortly speaking, when actions like "tap" or "expect widget exists" are detected, some logs are created, and screenshots are automatically generated. Later, they can be displayed in a nice GUI.
It is compatible with integration_test, since we still make use of that framework and only adds automatic logging and screenshoting to it.
(Disclaimer: This is a QA style question, such that people who need it can know there already exists a library and no need to reinvent the wheel, and I am the author of the open-source library)
I am using chaostoolkit tool and earlier the rollbacks used to happen if the hypothesis fails after the method injects failure. Now I see a different behaviour and the rollbacks happen only if i specify --rollback-strategy = deviated or always. I have raised a github issue as well which has sample console outputs(https://github.com/chaostoolkit/chaostoolkit/issues/258).
Does anyone know what could be the reason? or some parm to set the rollback strategy in the experiment itself instead of specifying at CLI?
I know it's been a while since this discussion happened. Just wanted to share my thinking on this.
Some time ago, I did a rather large refactoring internally and, as part of this, I believe I may have introduced this change without realising it.
I realised this some months ago but I'm not sure what path to take. My feeling is that I should revert back to the original, and specified behavior. But I'm concerned about the effect on existing deployments.
I have a question regarding workflow in Kanban. Can I have two activities in my name in the "in progress" column? For example, I started the activity 'A' but not concluded and will continue at another time, then I get the activity 'B.' Makes sense to have activities A and B in the "in progress," but I'm doing only one.
I am a certified Kanban Coaching Professional, and this would be my advice:
Sure you can. Kanban itself won't say whether you can or not, it depends on how you use Kanban. The WIP limits might prevent you from starting another task, in which case you should do some or any of the following:
Discuss the issue with the team, perhaps it is ok to raise the WIP limit (or even temporarily breach it)? Perhaps you can solve the impediments together and continue working on the original task.
Perhaps you can "swarm" or help someone else with something else on the board. I usually like to start from the right-hand-side of the board and see if I can help some other item move closer to done.
You can also treat this as "slack" time, and work on improving the process, learning a new skill, or checking emails, or some of the other tasks that everyone has to do that are not directly related to the value stream. "Preparing for working on the item" is what a lot of people consider doing, but is usually just cheating against the WIP limits.
I've decided to integrate OpenFeint into my new game to have achievements and leaderboards.
The game is dynamic and I would like user to be rewarded immediately for some successful results, but as it seems for me, OpenFeint's achievements are a bit sluggish and it shows visual notification only when it receives confirmation from the server.
Is it possible to change something in settings or hack it a little bit to show notification immediately as soon as it checks only local database if the achievement has not been unlocked it?
Not sure if this relates to the Android version of the SDK (which seems even slower), but we couldn't figure out how to make it faster. It was so unacceptably slow that we started developing our own framework that fixes most of open feint's shortcomings and then some. Check out Swarm, it might fit your needs better.
There are several things you can do to more tightly control the timing of these notifications. I'll explain one approach and you can use this as a starting point to explore further on your own. These suggestions apply specifically to iOS apps. One caveat is that these suggestions refer to internal APIs in OFSDK 2.8 for iOS and not ordinarily recommended for high level use and subject to change in future versions.
The first thing I recommend is that you build the sample app with your own product key. Use the standard sample app to experiment before applying the result to your own code.
You are going to get the snappiest response by separating the notification pop-up UI from the process of submitting the achievement. This way you don't have to worry about getting wrapped up in the logic for deciding whether the submission is going just to the local db or is doing the full confirmation on an async network transaction.
See the declaration of "showAchievementNotice" in "OFNotification.h". Performing a search in the sample app, you will see that this is the internal API used for displaying the achievement pop-up when an achievement is earned. It does not actually submit the achievement. You can call this method directly as it is called from "OFAchievementService.mm" to directly control when the message appears. You can then use the following article to disable the pop-up from being called when the actual submission occurs:
http://support.openfeint.com/dev/notification-pop-ups-in-ios/
This gives you complete freedom to call the submission at a later time provided you keep track of the need to do so. For example, you could locally serialize a flag to take care of the actual submission either after the level is done or the next time the app starts up. Don't forget that the user could quit out of a game without cleanly finishing a level.
I was working on something for a client today when I found a way to break some functionality in our program.
(The code is really legacy code, it's been in development for about 10 years and I've only been working here for about a year.)
It didn't cause an error, or cause the program to crash, but if a user was using the program and duplicated the behavior I'm pretty sure they'd be holding up their "WTF?" flag.
In our program we have named fields (textboxes) and static text (labels) that can be linked with the textboxes. When the textbox is not filled in the label(s) that were linked to them disappear.
The functionality that I broke was, when you change the name of a textbox that already has one label or more linked to it, and save the file, without re-associating the one or more labels associated with the textbox, the formerly-associated labels appear when the textbox is blank.
Now my thinking on the matter is that a simple observer pattern could have solved this problem in the first place, but then I didn't write the code.
I was thinking that if I could dig up more situations like this with the guys in my shop, that maybe I could talk them into considering unit testing, decoupling, applying patterns where they are called for and the like.
So for this reason I was wondering if anyone had any tips for finding broken (but not error causing) functionality in any sort of app (web-based, desktop, etc...)
For an app to fail usability, it has to have a defined set of expected behaviors.
"Is this textbox SUPPOSED to do nothing when the enter key is pressed?" Maybe it is, maybe it isn't. I've seen apps where a tester/reviewer reports something that they ASSUME should work another way, when in actuality the client specifically asked that they DON'T want the form submitted on a return key press, but only a submit button click.
So basically you have to define proper behaviour before you can determine incorrect behavior.
Hire some testers.
If it has an interface, then one of my favorite unconventional test is putting 5-10 year old children in front of it. You'd be surprised what they can come up with (especially the younger ones). While this may sound like a joke, it isn't -- it really works, because children don't have the mindset of only going through "mindset" paths.
And yeah, children are the experts in "breaking things" xP.
Code inspections, i.e. reading the source code: if you had taken time to read/inspect the source code, looking for "smells" or even just looking for code whose behaviour you don't immediately understand and agree with, you might have been holding up your "WTF?" flag too.
Test, test, test.
Do unexpected things. Start doing one task and switch another to see if anything goes haywire. Use the back button when you're not supposed to. Open it in two windows. Let it time out.
Test in all browsers, especially IE.
You can find database connections/sessions aren't released by:
working out the minimum number of connections you need to do something
setting resource limits to that minimum number
ensuring one "run" of the scenario that should use exactly that number (and release it afterwards)
then run it again a few times... do you run out of connections?
I used to work in a company where programmers regularly used to forget to de-allocate db connections. The standard answer was to reduce the resource to a minimum to see if there's a leak - and to try to work out where it is by restarting the system and running different scenarios repeatedly.
The first hour of code review, with the first reviewer, will do the most to find quality problems. But here's the thing: You don't need to convince people of quality problems. You need to convince them of the value of fixing bugs, and of rewriting only when the present quality absolutely justifies it.
I've dealt with some seriously bad code in my time. But you can't just rewrite. You need a spec before you can even tell if the rewrite is an improvement.
Sometimes, you have to infer the spec from the code and then check it against some human somewhere. But by the time you've done that, you understand the code as written and are now better prepared to repair than to rewrite -- most of the time.
Repair proceeds by a process of small behavior-preserving modifications that render the spec more clear in the code. Then, when you find something that looks wrong, you don't just change it. You ask around until you find the person responsible for that decision, and you get them to show you where in the spec it says that behavior X is correct. (This conversation can take many forms.) If you're lucky, they'll tell you that behavior X is in fact incorrect, and then you've earned your pay.
assert()
Also unit testing with coverage analysis.
This is particular to the Visual Studio IDE, although it probably also applies to others:
During testing, always at some point run in the debugger with "Break when an exception is thrown" turned on.
This can often help expose exceptions which are incorrectly being silently caught and which represent bugs, but otherwise may not be evident.
Code reviews should always also include reviews of the unit test code.
The problem is that with ad-hoc testing it's impossible to know how much or how well a developer has tested their code. So, you're at the mercy of different developers definition of the word "done".
If you include reviews of the unit test code at the same time you review the production code you should have a good idea of whether the code is really complete; in that "complete" includes "tested". Not just "Hey, I'll throw it over the wall to the testers!".