When unit-testing a component, the following question occured to me:
There are a number of mouse-related event handlers. I see two possibilties to test these handlers:
Simulate mouse events using Windows API calls.
Use the protected hack to access protected event handlers and call them directly.
I know that unit testing is normally restricted to the interface of a class (which also means that tests don't have to be changed when class internals change), but is this scenario worth an exception?
How do you usually handle mouse events when unit-testing components?
Personally, I think you need an architectural change to facilitate automated user interface testing. Reasons why are well formulated in this article: http://blog.objectmentor.com/articles/2010/01/04/ui-test-automation-tools-are-snake-oil
The Delphi Magazine once had an interesting article on automated testing of user interfaces from code (without a specific gui testing tool that is). Taking a bit longer to find than I expected and may not be available online. Will update my answer when/if I find it.
The article is "Creating Easily Testable User Interfaces" by Julian Bucknall (DevExpress) and was published in issue 120 of "The Delphi Magazine". Unfortunately the article is no longer online. You would have to buy the total collection of The Delphi Magazine: a 1 GB USB stick with all issues and all codes ever published in The Delphi Magazine. Well worth the 36 GBP! (And no, I do not get a commission).
Usually you are supposed to write your code in a way you can test it, so you test the methods you call by the mouseevent without simulating the mouse event.
In order to do that you need a good separated GUI and logical middleware.
Can you maby provide some Code or more information on the funcions you call on the mousevents in your app.
I think you are looking for some automated GUI testing. You could try Test Complete from Smart Bear, for example.
DUnit does offer some basic GUI testing facilities (in the GUITesting unit) but I don't think it may not be comprehensive enough for your needs.
Related
I don't understand LiveBinding's purpose. I would like to know which are the cases in which LiveBinding is most valuable. Embarcadero's manual describes it: "LiveBindings is a data-binding feature supported by both the VCL and FireMonkey frameworks in RAD Studio. LiveBindings is an expression-based framework, which means it uses binding expressions to bind objects to other objects or to dataset fields".
Thanks but I still don't know more than before.
I have seen some video in which a guy spends 12 minutes and hundredths of clicks to connect the caption of a TLabel to a TListBox control. When the user clicks an item in ListBox the name of the item is shown in Label. I could have done that with a single line of code (few keystrokes and no mouse clicks).
I am not criticizing LiveBinding. I am saying that I don't understand where it is helpful. I am missing something. Since it is not doing something that cannot be done from code, it means it's doing something that can be done from code, but visually and much much faster. I admit I haven't invested a lot of time in this topic but everywhere I look I see a terribly convoluted way (come on, you really need 5 extra controls to make LiveBinding works?) to do a simple task.
Also, it seems that LiveBinding was mostly designed for DB. All examples will include some kind of DB connectivity. But I am expressly interested only about the cases where I can use LiveBindings and there is no data set/DB involved. I am not using DB that much.
I doubt v. much that anyone would use live bindings if they could use traditional db-aware VCL components. However, that's not an option for non-VCL projects (Android, Apple, etc) and live bindings is the only Emba-supplied option for delivering data to those from TDataSet descendants.
An advantage of live bindings is that in addition to the Android and Apple targets, you can use them in Windows apps, so conceivably you could write the same (FMX-based) application for all three.
Libe-binding can also be used in VCL applications, but tbh, I can't imagine why anyone would use live bindings if they were only targeting a Windows DB application, as they are much slower than the traditional db-aware controls, especially multi-row ones such as grids.
I have not tried myself, but because the implementation of live bindings is interface-based, its potential use extends far beyond DB applications, but you would have to implement the interfaces yourself. It seems to be based around a fairly abstract expression-evaluation engine.
Setting up a l.b. project in the IDE does seem to require quite a bit more clicking around than you'd be used to from a traditional VCL app, but that's mostly because there is an additional step involved where you tell the IDE how to bind the gui objects to the data source(s). However, it is quite straightforward to "wire up" live bindings entirely in code if you want to.
I am newbie to BDD trying to understand it.. My understanding about BDD was ..
"Its a Kind of test where the user specfications are used to generate the Ubquitious language from the business"
But the examples i am able to see only the example of UI.. Like when the button is pressed .. when the user enters the text ... this wont form a language which i can use in my code..
Am i wrong in understanding this concept
BDD (Behavior Driven Design) was a term coined by Dan North and the best source to understand his intent is this excellent blog post
Here you can read that Dan want to shift focus from testing details to describe behavior instead. Of course this can (and sure has been) interpreted in oh so many ways :). So where ever you'll turn to you'll get an opinionated view - here is mine.
The idea with Cucumber-based tools, like SpecFlow, is to write down the teams shared understanding of a feature in a language and tool that all involved can read and understand. This is done (again in Cucumber-based tools) by writing down a couple of scenarios or examples on how the feature can be used. Some people call this specfication by example.
Some goodness comes out of writing the specifications by the use of examples in this way:
you can discuss the behavior of the feature before it's implemented
the specifications gives you a great specification to code after, using the outside-in approach
the specifications over time becomes regression tests that verifies that the system behaves as specified
the specification also comes through on a old TDD promise and becomes a living documentation for the system. You can easily see what the current state of an feature is by looking at the executable specification that the feature has passed
So now finally to your question (which by the way is a great one that I often have asked myself and others). Excuse me for rephrasing it, I hope I catch your intent:
Do my scenarios have to (or should they) be run against the UI?
You sure don't have to run the scenarios against the UI - the principles of BDD and the tooling works great going against your domain in any layer.
But to get the most out of your specifications you should consider my (inconclusive) list above. If you don't include the GUI (or the database, or services etc.) then you cannot be sure that the whole application stack works correctly together. So very often the specifications are run End-to-end.
And this makes these "test" something very different than your unit-tests (which you want fast as lightning, mocking out external dependencies, not hitting the database etc.). They take longer time to execute, all of them should not be run on every check-in, the don't use mock etc.
Often you start out with a step of a scenario and as a driver for a behavior and then use ordinary TDD to drive out the details of the internal of the system. This is outside-in programming.
Finally to your example above. So I recommend you to run your specifications against the UI end-to-end all the way to the database; but I would advise describing the UI in technical terms as above (using buttons, links and textboxes for example). When I asked this question on the BDD Google Group I got a great tip from Elisabeth Keogh:
Don't describe the UI. Describe instead what you're trying to achieve with the UI.
So to describe a login feature don't write:
Scenario: Login (describing the UI)
Given I am on the Login-page
When I enter 'AUser' in the textbox 'UserName'
And I enter 'APassword' in the textbox 'Password'
And I click the 'Login' button
Then I should see the following text 'You are logged in'
rather write it something like this:
Scenario: Login (describing what we want to achieve)
Given I am not logged in
When I log in using 'AUser' and 'APassword'
Then I should be logged in
That leaves the complexity on how this is done (click buttons, filling out forms, checking messages etc.) is done in the step definitions that you write in code.
I hope this was helpful. Also I am bracing myself for some "bashing" that can come from other, more experienced BDD-people. But hey, this is my two cents :)
I'm still pretty new to BDD and Specflow too. We've been using it to establish behaviour and code out the controllers, which in turn drive out the views. I don't have a code example in front of me, but I'll try to find something to post later. Cheers!
edit - BTW, if you're looking for a good book on using Cucumber (it uses the same language as Specflow - Gherkin? I'm still getting all the pieces straight), I can highly recommend The RSpec Book from Pragmatic Programmers. The code is Ruby based, but there are some higher level chapters on project definition and running. Well worth the price.
I'm working on Windows XP/Delphi 7. I need to add some procedures (or functions) inside a program that is running, and I do not want to re-compile it once again after I finished it.
I just have a host application with 5 functions to send different types of alarms, but there are other new alarm types, so I have to do new functions to send those alarms, but I should not re-build the host application. I have a class named TAlarmManager that it's invoked calling those functions.
Maybe a plugin?? OK, but how can I "insert" new functions??? Tutorial, manual, book, etc.. for learning about this, or any advice on how to do this???
I have studied plugins (I'm totally new on this theme), but no one "talks" about adding functions to a host application. It seems to me that plugins add functionality from itself, I mean, they have been developed with self code to do something, not to "add" code to the host application... How can I do this??
For the technical side: How does the Delphi IDE do it? That would be the first place for me to look.
To understand plugins, you must understand that you can't add new functions. You could but since the old code doesn't know how to call it, they wouldn't be called.
So what you do is you add a "register" or "start" function to your plugin. That start function gets a data structure as parameter which it can examine or extend. In your case, that would be the list of alarms. Alarms always work the same (my guess), so it can add additional alarms.
The main code will then, after registering all plugins, just walk over the list of alarms and invoke the standard alarm function on each of them. It no longer cares where each alarm comes from and what it really does.
The key here: You need to define an interface which both sides subscribe to. The main code calls the interface functions and your plugin code implements them.
Another option available is to use a scripting component to your project. One which works quite well is PascalScript. This would allow you to load external scripts after the fact and then run them as needed to interact with your application. As Aaron suggested you will also need to still provide an interface of some sort for your script to interact with your application.
See also Plugins system for Delphi application - bpl vs dll? here on Stackoverflow.
I'm not quite sure what you mean by "alarms", so I'm making a couple of assumptions.
1) If you don't need additional code for the alarms, I would try to make them data driven. Keep the different kinds of alarms in a database or configuration file, which makes it easy to update applications in the field without recompiling or reinstalling.
2) If you need special code for each alarm, you could use run time packages as plug-ins for your application. Search for Delphi runtime packages to get some ideas and tutorials. Here are a couple of links I found:
http://delphi.wikia.com/wiki/Creating_Packages
http://delphi.about.com/od/objectpascalide/a/bpl_vs_dll.htm
3) Scripting, as skamradt already mentioned. If it makes sense for your application, this could also let your customers write their own add-on functionality without requiring a recompile on your part.
You almost definitely want to use Pascalscript, as skamradt suggests. You should start here, and seriously consider this option. There are many possibilities that come out of being able to serialize live code as text. The only downside is possibly speed of execution, but that may not matter for your application domain. I would have upvoted skamradt, but I don't have enough reputation to upvote :)
Some time ago I was looking at a situation sort of like what you're describing.
My answer was .DLLs. I put the variable code in a .DLL that was dynamically loaded, the name specified in a configuration file. I passed in a record containing everything I knew about the situation.
In my case there was only a success/fail return and no screen output, this worked quite well. (It was commanding a piece of machinery.)
This sounds like a place where a scripting language or "Domain Specific Language" may make sense. There are several approaches to this:
Implement alarm functions in VBscript (.vbs files written in notepad) that accesses your Delphi code via COM API. Using the COM API gives you access to a large range of programming tools for writing functions, including Delphi. This is the most clumsy solution, but easiest to do. It may also be a benefit to your sales process, and it is always good to think about how to sell things.
Implement your own function language in Delphi. This way you can make it so easy, that your endusers can write their own alarm functions. If you do it as an expression evaluator, you can write an alarm as 2*T1>T2. There are several expression evaluators out there, and you can also write your own if they don't match your needs.
Use a predefined programming language inside your Delphi application, for instance, "Pascal Script", see http://www.remobjects.com/ps.aspx
You should take a look at PaxCompiler, like PascalScript it allows to load scripts, but you can even precompile them before for more performance. Look at the demos section for the solution of your problem.
As a side note, the web page really looks bad, but the package is really powerful and stable.
I think that the scripting solution it's good for this situation.
There are many scripting packages that you can evaluate:
Context Scripting Suite
Fast Script
RemObjects Pascal Script
TMS Scripter Studio
paxScript
Other packages that you can find on Torry, DSP, VClComponents,...
Regards.
I'm building a test harness for my Delphi 2009 app. Testing the logic is fairly simple. Making sure the forms work properly is proving a bit more complicated. I'd like a way to simulate real user input, to open a form, make it think there's a user typing certain things and clicking in certain places, and make sure it reacts correctly. I'm sure there's a way to do this, I just don't know what it is. Does anyone know how to do it?
DUnit has GUITesting.pas whicih extends testing so you can send clicks, keys and text to controls on form, but that is about it.
Last year there where mentions of Zombie GUI testing framework that was used internaly by CodeGear developers, but nothing since Steve left for Falafel.
TestComplete is a good choice. Another commercial option for GUI testing is SmarteScript:
well for .net there's NUnitForms for GUI testing a win application.
don't know any open source for delphi though.
Test Complete can test delphi forms but it's not free.
There's 2 parts to this, firstly how do you automate the GUI, and secondly how do I then 'test' whether its working/not working.
Firtsly: To automate the GUI on windows try using AutoIT. Its a free tool for controlling windows interfaces, sending keyboard input events etc. http://www.autoitscript.com/autoit3/
Secondly: Testing is a big field, and I won't try and give you a whirlwind tour. But the mechanics of driving the GUI and testing the results could be handled using AutoIT's built in Basic like language or by using it in conjunction with a language like Ruby and TestUnit (rubys built-in unit testing framework).
If there is nothing Deliphi-specic out there and you need a quick solution try some easy to learn scripting solutions like AutoIt.
For a bit more sophisticated scripting, you might have a look on Scripted GUI Testing with Ruby.
But be aware, that you should not test too much functionality via the GUI, because such tests are very likely to break. If you end up with too much GUI testing you may need to rethink the design: Decouple logic from the GUI and test the logic directly with some xUnit framework.
Also have a look on a similar question about windows forms test automation.
It seems like DUnit has some gui-testing functionality: delphiextreme.com
Not exactly an answer to your question, but there is a very good page (IMHO of course) about GUI Architectures by Martin Fowler, featuring the "Humble View" architecture as the last entry, which is geared specifically towards test-driven software development. Worth looking into.
This will of course not help you with the task of testing whether all controls are wired correctly and handle all necessary events, but it should help to minimize the amount of GUI code that does need testing.
OpenCTF is good for you.
Quote:
OpenCTF is a test framework add-on for Embarcadero Delphi® which
performs automatic checks of all components in Forms (or DataModules).
It provides an easy way to build automatic quality checks for large
projects where many components have to pass repeated tests.
Adding OpenCTF tests to a DUnit test suite requires only a few lines of code.
Writing your own custom component tests needs only a few seconds.
OpenCTF is based on the DUnit open source test framework and extends
it by specialized test classes and helper functions.
Please head here to download.
I know there's an API for creating extensions to Delphi. I use the GExperts package and various JVCL experts frequently. But I've never seen any extensions to the debugger. It would be very nice, for example, to be able to register viewers for various objects instead of having to examine them in the Inspector. (A form with an image control that displays a TImage, for example, or a grid that displays the contents of a dataset.)
Are there any APIs that allow you to extend Delphi's debugger in this way?
EDIT: This wasn't available back when I wrote the question, but Delphi 2010 provides a way to do it.
In ToolsAPI.pas source there is some API interfaces for debugging. You can be informed when a debugging event occurred, info about breakpoints, which process is being debugged etc. with this API. But it seems there is no support for variables or values of them. So there is no easy way to implement your requisition without ugly hacks.
Basic debugger visualizers can be implemented with the Evaluation interfaces exposed by the OTA. (Examples for debugger visualizers can be found here and here.)
A deeper integration into the debugger is possible as well (for example, I wrote a little extension for C++Builder that enables the debugger to evaluate the actual objects behind an interface) - but as Khan pointed out, to achieve such a level of integration, you'll need to resort to quite a few dirty hacks.