Mike Torrettinni

So, it's more like: start with test cases that produce exact results as expected, then slowly expand to test for most commonly expected 'wrong' input. Stop when it makes sense.

OK, this makes better sense. Because testing Calc examples of x+y makes sense to test -MaxInt.. 0,1..MaxInt examples. With string or lines of string... it's 'unlimited' possibilities.

Not sure if what you are referring here is same as I do now, but I have 'test cases' where I have exact input and output as text files. I run test with previous and current build and compare results (text files) if new build changed anything. Tests like these makes sense. So, I'm having hard time going from such test to this: I understand we have to test almost every method we have, but Calc and it's family of tests have limited input. How do you test parsing a line from text file? For example, if text line is expected to be in this format: A B C D or A B1, B2 C D. You can test for a few examples for parser to parse correctly and identify A B C and D parts. But if you define test case for these 2 examples, what's the point of test case, it already works.

What does X stand for?

Thanks, I saw that blog, but it uses similar Calc example. I'm having the same problem with such examples like when I was learning about classes and I found plenty examples with animals, TAnimal, TDog, TCat. I guess my imaginations is not good enough to go from test case of x+y to real life example, like file parser. I don't need extreme version, yet, so DUnit is just fine for me. I found the one short chapter on unit testing in Expert Delphi book, by Pavel Glovacki, no other books on this topic, for Delphi.

At first I couldn't imagine why could this be useful. But then I thought about all the little visual changes I need to do to on some forms to fit the desired look, and being able to hot reload a simple change of position or alignment or text and no need for reloading the project, this wold be really cool to have. Not sure how could it be useful for anything more than simple changes, but even just for my use case, I would vote for the 11.1/11.2 patch to include this feature!

I'm putting a list of tasks together that I do for every update, release, or just in general around the project, so that I never forget anything and also to see what I can automate or streamline. So, I'm interested in what kind of steps, tasks do you do in your CI process, manual and automated. So far I have, in the process of update release: manual, before automated: - copy user guide files to common destination - prepare change logs run automated (cmd script): - git commit (comment: version number) - build project (msbuild script) - create installers (Inno setup) manual, after automated: - to ftp - prepare and send update emails So, not a lot automated, yet. I don't run test cases, so I assume most of you will have this part of the build process. At least I'm missing these tasks in automated part, which I still plan to integrate : - backup projects and all important files, docs - git Push I assume some of you use FixInsight as part of the build process for final check before release, right? Do you use any other tools for build process to check for code? Do you do any reports, like summary of code changes... I can't even imagine what kind of task list a large team has, or someone who deploys to other platforms.

I re-read this topic and I assume my tasks are still way too simple for FinalBuilder: Even though I have more tasks now and a few more are coming, I guess still staying with batch files, for now.

No, but the video looks a bit confusing to me with all the parameters setup. Perhaps my simple builds are just not suitable, too simple for it. I only see download for client/server version. Does it also come in a standalone, client only version, or does it need server running all the time?

Interesting, my commit messages are not same as what users see, need. Commits are more about code change, while changelog gets end user feature change info, so I need to manually write them.

what does this mean, automated changelogs? or this is manual pre-check?

The push is last action in my process. I only make new build when is ready (enough changes implemented) and then run the whole process. When all is done, I verify the commits and if all aligns I push. I don't really see Github as a backup, I see it more as a storage. But need to automate another backup to local disk. I use Archive from SourceTree that creates zip already. Perhaps this can be automated, or I guess directly from git. Thanks, Continua CI looks interesting.

I know the feeling, no tests. But I started running test for 'output', so if same input produces the same output from previous version. This is 'easier' than to write test cases for old code.

I'm actually still at the point when I regularly check the automated parts... if git did it's work, if installers contain appropriate files, when I do ftp I always download the files to check... and some details change, get improved almost monthly. So, still in progress.

If you are thinking of writing blog about the issues you had and how you resolved them, I would very much like to encourage you to do it. I'm sure I'm not the only one who will deal with this in near future.

I had some issues at the beginning when I installed W10 fresh. I tried to disable updates but they kept coming back online, but as soon as accepted the behavior and let it update everything and after a couple of days it was all good. Now I just press Pause for 7 days when it notifies me of new updates, if I work on something and can't shutdown. And updates are so much faster and reliable than W7, it's not annoying anymore. Never experienced any issue with updates, except when I tried fighting them 🙂

I'm updating my installers and came across the info that Microsoft is recommending to skip welcome pages and go straight to the actionable content of installer: https://docs.microsoft.com/en-us/windows/win32/uxguide/win-wizards#wizard-pages I've never had anybody complain about the welcome page and I see it as a confirmation or introduction to what users are installing. Even though the setup name includes product name, it can happen the setup name is changed into something more generic for delivery purposes, so the welcome page shows the exact product version. Is this something I'm behind the progress and this is 'the new thing' with installers? I'm curios what you guys think of this, did you remove the welcome page from your installers for any reason?

Yes,I never had problems with Innosetup. Actually with first versions, years ago, I didn't even know some customers use /silent option to install my software. I only learned that later. So, it's working out of the box.

This is still just an idea, but 1 click is meant that all important/needed info is on 1 page, including installation folder, and Install button. Review the info and install. Simple, quick.

Interesting. I'm still trying to come up with 1 page/click installer and I hope I can come up with process that allows it. But EULA should be part of the setup, as you expect this kind of useless stuff to be there. Not in the app, once installed it should be ready to be used.

???

I was tempted to create 1 page setup, only having the real necessary information, but squeezing in the EULA window is a little tricky. But interesting, for sure!

Actually I forgot one detail that half of my users install my tools as a 3rd party product with bigger product suite, so the welcome screen is needed so users know what is being installed. Interesting Microsoft doesn't have guidelines for all these various installation options.

You are right in a way! I think there is a difference between download and install (which happens less often) vs 'check for updates' and install (which can happen weekly or bi-weekly for a lot of software). I really don't like notepad++ or filezilla cumbersome update every couple of weeks. Annoying. In my case my projects are usually installed couple of times a year. Not all users always install all update versions throughout the year, so having welcome page to show the exact version they are installing is quite welcome. And I have 'run project' checkbox at the end, default non-checked.

I hope the title present the question correctly, so here it goes: One of my projects got to the phase where there will be no major yearly releases, anymore. But quarterly or monthly updates. So, no more 6-12 months development of new features and then releasing all at once. I think this is called sprints...? Anyway, in the past, to avoid multiple branches (1 for bug fixes, 1 for new features), I would only have 1 branch and new features would not be published. Simple, to avoid duplicated bug fixes implementation. New features would be hidden while old release bug fix updates are released, and enabled in menus on new release. But now I will make big changes to existing features. So I need to find a way to manage changing current features and releasing bug fixes before all the new changes are implemented. It's easy when you add new controls (button, checkbox), you have them hidden until release date. But what if you change the layout or making big changes but are not ready for release when is time for bug updates? I want to avoid duplicating features, views, frames, code and then switching to new ones on release. Is there a way I can avoid all this duplication? Any advice is appreciated!