I've got a C# form, with various controls on it. The form controls an ongoing process, and there are many, many aspects that need to be right for the program to run correctly.
Each part can be unit tested (for instance, loading some coefficients, drawing some diagnostics) but I often run into problems that are best described with an example:
"If I click here, then here, then change this, then re-open the form, then click here, it crashes or produces an error"
I've tried my best to use common code organisational ideas (inheritance, DRY, separation of concerns) but there never seems to be a way to test every single path, and inevitably, a form with several controls will have a huge number of ways to execute.
What can I read (preferably online) that addresses this kind of issue, and is there a (non-generic) term for it. This isn't a specific problem I'm having, but one that creeps up on me, especially with WinForms.
You're trying to do acceptance testing, not unit. It is useful to test whether all bricks of your system are properly connected together. But bricks themselves should be tested with unit-tests.
So if you have a functionality that takes some coefficients and makes diagram, test it separately from GUI from all sides. Give it all possible edge-cases of coefficients and test point coordinates it returns. It was just one unit, there will be dozens, hundreds or thousands.
After you're sure in your units, do few functional/integrational/acceptance tests to make sure your units play well together.
For unit testing you can use NUnit or built-in test system.
For acceptance testing look at FITnesse or search for commercial products.
And to get an idea of how to divide the application in units, read about MVC and similar architecture solutions.
Each of those principles (inheritance, DRY, separation of concerns) is not a guaranteed recipe for high quality code, of course. If you use your inherited and DRY method to divide by zero, then you're still doing something wrong.
My advice for hard-to-trace errors: logging! Log the internal state of variables at key points in the user's steps to reproduce the problem.
I'd try and map common user UI workflows (with slight deviations, perhaps using "foreach" on control lists to pretend you're a user spamming everywhere and changing stuff) as unit tests.
I wouldn't go as far as (click at (x,y)) but more firing events like "txtUsername_Focused", "txtUsername_TextChanged", "btnBack_Click", "btnForward_Click", "btnSave_Submit", of course with some handling if you get different forms showing as a result.
I have faced this problem (test every single path) with Windows Forms. But after moving to WPF,Silverlight the problem is solved. Use MVVM along with command pattern (basically ensuring that you have no code in code-behind files). Ensure that you have single responsibility classes. In your unit tests, you can simulate every scenario including button clicks and you will be able to test all possible paths.
I am not sure how you will be able to use MVVM and command pattern in WinForms. But, I am google will definitely provide you with some answers.
Related
I am developing a winform application where a set of classes and its methods calculate a geometry from 3d points.
As there is some input from the user needed from step to step in the algorithm we have designed some buttons which represent the steps. The intermediate data is stored in a class (maybe we use a structure in future Versions), so as the user input is. As result of pushing the Buttons the intermediate data will be calculated, saved and shown to the user, so that he can edit it, affecting to the calculation in the next steps.
The application began as an application which calculate everything in 4 steps but now we have more than 10 steps so we have divided it into 3 parts (horizontal geometry, vertical geometry and other...). Now I am doing some divisions because everything is getting too complex to manage all the gui interaction in one Form so I will create user controls for the smaller parts of the form.
Do you have general recommendations for me?
Should I have these data structures (input and intermediate data) in the controls I make or in the general form?
You should avoid mixing UI with the business logic. In that way when the program grows larger it will be a lot easier to maintain. It will also make it much simpler to write automated unittests.
If there is no particular reason you are using winforms. I would recommend using Windows Presentation Foundation (WPF). Read a tutorial about the Model View ViewModel (MVVM) design pattern. This is a very nice way of separating the UI logic from the business logic.
It takes some effort to switch from Winforms to WPF but it is definitely worth it.
EDIT (answer to comment)
Well it depends on the problem your solving. But generally:
In the MVVM pattern the:
Model would contain all your data and algorithms in classes/methods. The ViewModel would connect all the stuff you have in your Model and control the flow of the program, it will expose properties (commands, strings, numbers collections etc...) that view can bind to. The View is simply a "skin" that makes it possible for the user to communicate with the ViewModel. This is a very simple explanation of the MVVM pattern and I would recommend reading a tutorial about it.
The first time I came across this pattern it was called Model View Controller MVC, I like what AngularJS is doing by just calling it Model View Whatever MVW because there are a lot of MV* out there. But WPF is specifically built for MVVM.
The most important thing, if your creating a program that is going to be used and maintained for many years, is to keep the code as simple as possible. Instead of writing all the functionality into the Button_Click event handler (I have seen some programs that do this), try to write a class or method for every single task (use long descriptive names), this is also called Seperation of Concerns. In other words one method/class should not do more than one tasks. The nice thing is that you end up with a "program flow controller" (ViewModel/Whatever) that just passes data from one method to the next. And just by looking at the code you go: Aha I know exactly what is going on here! In the same way when you look at your algorithms (Model) they should do a single job and all variables should be have descriptive names. This makes it very easy for other developer to understand the code.
I also have very good experience with dividing my namespaces according to type. So every time you have more than one object of some sort (DataProviders, FileReaders, etc...) create a namespace/subnamespace for them and put them in there. So when your creating a new object/interface/enumeration... you always know where to put it. And you always know where to find again: Oh its a DataProvider so it must be located in ProjectName.Objects.DataProviders :)
So my recommendation is: have some fun and read about: MVVM and SoC
Probably state machine diagram will help you do devide actions in parts. It's a better practice, to create some of diagrams before codding.
Basically i am working on UI automation testing of a windows based application using visual studio CODE UI, problem comes as and when the layout changes or some new control is added in the GUI,and the control ID of the controls change.As we can see from the screenshot that a typical hierarchy is recoreded by CODE UI builder which is :-
Main Window ->Window with Control Id property -> Actual control.
So here are my questions related to this heirarchy and control Ids?
1) How are these Control IDs generated?
a) I know there is some logic by which these control ID Nos are
generated, depending on the depth of the control in the GUI,but i am
not able to find out any consistent way of how they are generated ,
for example in images the two buttons connect and help seems to be
in same level of GUI but still their control IDs are so different 1
and 5013.
b) Are these control IDs generated by coded UI builder used in Testing
environment or there is some logic in product development side or that code itself
by which they are generated
2)Is there a way to skip this middle layer of window with control ID and do the record and playback successfully.(As in my case we have access to logical name of all the controls which themselves are unique in nature ,and we are good to get rid of these control IDs)
3)Plus Can we have hybrid approach where we have two layers for almost all controls but three layers for some special cases where its not possible to work with logical name or label only and we explicitly require control IDs
4)Last but not least how much of the accessibily implementation of this type can be done in Testing Environment as per my knowledge most part of accessibilty of controls has to be done on the product development Environment by adding some properties in code itself which then can be retrived for testing using various tools like CODE UI in testing Environment.
But for large scale products i dont think that is a good approach as it imposes extra burden on development side and it is like adding extra unnecessary code in product(needed for testing purposes only) which needs to be delivered to the customer.
Plz see images below as a reference for clarity on my questions.
1st Image shows Remote Desktop GUI
2nd shows Computer: control properties recorded by CODED UI
3rd shows Connect Button properties recorded by CODED UI
4th shows Help Button properties recorded by CODED UI
I am only starting with CodedUI now, but I did a lot of UI Automation using different products before and using the same technology (MSUIA etc.). So this should apply here as well.
Each control has several properties, like name and automationid to name the most important ones. If you are automating a UI that is your own (you code/build it yourself) you should always attempt to give a unique automationid to each control, that will make your life a lot easier when automating. Name often is a bad option, since it frequently changes when you have a different language version of a program.
Since in that case you do not have the source and cannot influence the values it reports, you have to work with what is given. Still, even though CodedUI recorder will choose any property it sees fit, you can change the search criteria yourself by changing the UIMap.uitest for each element found:
This probably will take some time getting used to.. especially for more complicated UIs where elements have similar properties, also for dynamic UIs, etc.
By the way, the products I was using earlier on directly were working with AutomationElements, and here you have the full power to select and do what you want - even though with a high maintenance and start cost. (Ok, so it is generally very time consuming - and will always be more time consuming than using any ready solution like VS Coded UI.)
One more easy solution also is to simply go by coordinates (relative to some known controls, like main window or a tab group), this also will work 99% of the time and bring you to your goal that much quicker.
Ok, answering your concrete questions
1) if that is what I think it is, they are generated at runtime and there really is no relying on them
2) When going lower level (like AutomationElement) you can search whole trees. Still, that will typically make the search rather slow as well - not much faster then if you get the whole tree yourself and traverse it
3) You can mix anything you want. Actually, you can even convert handles to AutomationElements to Controls (at least for most standard controls). So you could use any technology, like Win32 SDK, to traverse the tree. Actually, all GUI trees in all technologies are similar - though not the same. And few people coding seem to adhere to any standards.. at least that is my experience.
4) Using a variation of technologies, coordinates (actually, I even used screenshots) etc you can achieve almost everything. It takes a lot a lot of time though. Getting the basics right during development and taking feedback from UI test developers into account can greatly help speed up later testing.
Simplest example: whether an application paints "all ok" on the screen or whether there is a control that can reach that has a name property that says "all ok" - second solution will be a lot better for the automation guy.
Also, for more complicated UIs, if you are in a corporate environment, have some money and want to spend a lot of time on UI tests anyway, I suggest a product like Ranorex, SilkRunner and the like. I worked with a Ranorex Eval for a few days and (after some getting used to it) could navigate UIs that very rather difficult to navigate myself beforehand.
I've got an ASP.NET web application, that is essentially our intranet site. I made a lot of progress on the administration office's employee management pages. It ties into an SQL server database, and I'm using a three layered design (Objects, Logic, DataAccess). It was all reviewed and all of it was accepted, except! for the part that manages vacations and vacation histories.
My question, before I go into details is, how does one efficiently "untangle" code that is no longer necessary?
For example: previously I was treating each VacationDay as it's own entity with it's own history. Such that I could track the history of an individual day. To help in tracking, I have an enum called VacationDayAction, which includes options such as .Submitted, .RequestDenied, .CancellationRequested, and so on. This was in an attempt to provide meticulous detail for each day. It was then determined that we no longer need that. We do, however, still need VacationDays and all the basic functions of that (saving days, getting days, etc.), but now we no longer need any of the "history" related classes.
My problem is, when I right click a class that I no longer need in VS and go to "Show All References," I get a ton of results scattered across several pages. I need to get rid of all of them, without breaking the rest of the application. Is there not some kind of "smart" technique or method for easily untangling parts that are no longer necessary? This is particularly difficult because 90% of what I did was just fine, and needs to stay like it is. Yet scattered in that 90% is 10% of stuff that is no longer needed. I can't just go storming through with the delete key either, because with the removal of each reference, I need to be sure that any dependencies on that reference are also fixed in a way that they don't call stuff that isn't there anymore. And I still need the application is a compilable state, so that I can test along the way that the rest of the application didn't fall apart as a result of some deletion.
To give you an idea of my low level of experience, I started two years ago with having never used C#, ASP.Net, or Visual Studio. It blew my mind when, way after starting and as I was learning, someone taught me that I could use breakpoints. And then it really really blew my mind when I learned about multi-layered design. I'm wondering if there is not some technique or trick or feature that can help in scenarios like this, where you have to "untangle" and throw away unnecessary stuff.
This is not a simple question. In fact, I would say this is one of the major challenges for any systems developer; how to handle and get rid of old code which is not in use. There is lots of literature on this, and few really excellent answers. A good book may be "Working effectively with legacy code" by Michael Feathers, which deals with many related problems. It is no light read though, and will probably take some time to get through, but it will likely help you become a better coder, and better at these kinds of tasks in particular.
Maybe you can have a look at the Resharper tool? ( http://www.jetbrains.com/resharper/ ) It is a productivity tool which among other things shows "dead" code (unused code) in grey, and lets you remove it. It will also help you remove unused references from each class (again, they will be grayed out and let you remove them automatically).
Drawing diagrams where each major piece of code /component is a box with a line linking it to any related component might help you get a better overview; try to draw a hierarchy showing how different parts of the code are related and dependent.
The bottom line as far as I know, is that you just have to muddle through it, commenting out code a little at a time, then recompiling and testing it. If it still works, fine, now you can remove the commented out code completely. This would be easier if you had unit-tests covering your code, but I take it as a given that you don't, as is unfortunately often the case.
I just had a conversation with my manager relating to checkin\out policies on a project I'm currently working on. Basically I tried to edit a file that was already checked out by another developer and I couldn't - I asked my manager why we couldn't edit the same class at the same time and he gave this reason for turning that functionality off: We had a lot of problems with developers editing the same Form (or anything visual done in the designer) and then cheking it in. Merging the changes in the designer generated code was a lot of hassle...
As I'm writing this I'm struggling to see what problem they were having - surely they were getting the latest code before trying to check something in??
Have any of you come across problems with editing the same Form (or something in the designer) as another developer and then checking into TFS? If so how did your team get around the problem? Did you also turn off the ability for developers to work on the same class?
EDIT: The following post (found here) is exactly the problem my manager was describing. Anyone know of a simpler way to resolve the issue than the ones in that post?
I would argue that the solution to your problem would be to establish best practices for source code modification.
Discourage people from going into UI code and arbitrarily jiggling the components around in the designer. Any reasonable UI modifications should be easily mergeable. Your best bet is to try and educate people as to the best way to merge in any given source control system. Also, as helpful as the designer is, ignorance of what code is being automatically generated in the background will be significantly detrimental in the long-term.
People who insist on locking checked-out files for the reasons you stated in your post typically wait long periods of time to check their code in. Naturally, the more time passes, the more code gets modified, so it makes merging difficult for these people. Checking in early, often, and incrementally requires people to think about their changes in stages, and for some coders, this is a rather painful cultural/psychological adjustment.
I've just checked back through the histories of some of my .designer.cs files and I can't see any changes that would cause a merge problems. There were no wholesale rearrangements of code for example.
Another thing to consider is to make sure that everyone does a "get latest" at regular intervals then any individual merge/resolution isn't going to be that great thus minimising the chances of anything going wrong.
It might also be worth investigating a 3rd party merge tool. There are plenty around.
Now it could be that the changes I've done are simple compared to the ones you've got so you should take my anecdotal data with a pinch of salt.
It can cause problems (in general) when a lot of people are editing UI concurrently. The merge logic will do a fine job merging things, but in a lot of cases the UI is drawn according to how things are added to the form. Your UI can get messed up quickly.
I don't know if I would use this as an excuse to enforce exclusive checkouts across the board, though. I might go from a (non programmatic) policy standpoint that says shared checkout for business logic, but exclusive for UI changes.
I would couple that with a strong MVP, MVC, or MVVM approach, though, which should limit the number of people that have to touch the UI concurrently.
As others have alluded to, keep one of the seminal rules of SCM in mind: merge early and often, and your problems are reduced. (along with that is "always get latest before you start working on the code).
If it is possible to auto-format code before and after a source control commit, checkout, diff, etc. does a company really need a standard code style?
It feels like standard coding style debates that have been raging since programming began like "put the bracket on the following line" or "properly indent your (" are no longer essential.
I realize in languages where white space matters the diff will have to consider it but for languages where the style is a personal preference is there really a need to worry about it anymore?
Auto-format can really only address whitespace.
It wont address developers giving variables bizarre nonsensical names.
It won't address some developers having functions return null on an error vs throwing an exception.
I'm sure others can think of more examples.
This is what we do at my work:
We all use Eclipse. We don't have a policy for using Eclipse but somehow none of us is an IDEA/IntelliJ guy. We also think our code should be written with legacy in mind. This means our code has to be readable in a certain way even years after (#1) no matter who wrote it and if that person even is in the company anymore.
Eclipse has couple handy features, automatic format on save and a specific Formatter tool. As you can see from the linked screenshot, it can be configured with XML. Thus there's a bunch of premade XML:s available for every worker in our company so that when a new guy comes in, we walk him through of the whole process and configure their Eclipse for them (yes, it's slightly evil thing to do) so that it actually uses those formatting XML:s we have provided. We do not enforce automatic format on save, we don't want to be completely intrusive, we just want to push all our developers into the right directions. For even increased compatability, we mostly use rules defined in JCC.
Next comes the important part, the actual builds. We are those who embrace automatic builds and for that we use Hudson Continuous Integration Server. There's two important parts in our configurations beyond this:
We use CVS loginfo to trigger builds whenever something is committed.
We utilize several plugins available for Hudson, including Continuous Integration Game in conjuction with the most important one, Checkstyle.
The Checkstyle Plugin is the magician in our code style enforcement guide line:
After commiting code to CVS, Hudson build is triggered
After build has been completed succesfully (all unit tests pass etc.), Checkstyle inspects the actual source files
Checkstyle ranks the code based rules we have defined for it
Continuous Integration Game sees the result of Checkstyle and awards/takes away points for the person who has the ownership for the relevant part of the code
Leaderboard shows total points for every commiter in system
Basically this means that when anyone commits ugly code into our CVS, our build server automatically reduces that person's points.
This means that eventually any one of us can be ranked on the Leaderboard based on the general code quality in both look and OO principles such as Law of Demeter, Cyclomatic complexity etc. etc. Naturally this isn't a completely serious statistic, but it's a good indication you're doing something wrong when causing a build to be initiated in our CI won't reduce your points - most of our commits are worth between 1 and 5 points.
And is it working? Sort of, I don't think anyone of us at my work writes ugly or unmaintainable code and personally I love to hunt all kinds of scores so it's definitely motivating me to make code that looks nice and follows all the OO paradigms I know of.
And do we as a company really need it? I think we do as you should see from reading this entire answer, it can be considered a good practice for the advancements it brings.
#1: in a related note, I refactored legacy code from 2002 today which used those standards, didn't look "bad" at all even in its original form and certainly not worse in its new form
No, not really.
If you can actually get it to work consistently and not make it flag code has changed due to a different style of laying the code out.
However, this is just a small part of coding standards. It won't cover multiple return statements, the use or not of ternary operators, etc.
It is always nice if the coding style that the shop uses is the same one that is also followed by the development tools.
Otherwise, if there is a large body of code that already follows a shop standard which is NOT the same as that of the tools you have two choices:
Modify all of the code to follow the tool standard, or
Maintain the existing shop standard.
Many shops do the latter. Regardless, there does need to be some kind of standard, and it does need to be followed.
Some development tools allow you to tweak their standard. In some cases you may be able to bring the tools in alignment with the shop standard.
It probably doesn't matter that much anymore if you can ensure that everybody in the team sees the source code "correctly" formatted, whatever they think it is. However I've not seen a system that can do that - you can do parts of it (say, reformat before and after checkin/checkout) but these days you also have to consider web interfaces into the version control, external code review systems that interact directly with the version control system etc.
The main purpose of a standard code style is (IMHO) to ensure that you can read other team members' code easily without having to start reverse engineering it because all the code is written using the same sort of guiding principles. Indenting and parentheses placement seem to be a major hangup on this but they are only a very small and in my opinion, somewhat overblown and not very important part of the need to make code consistent.
Unfortunately I'm not aware of any tools that can automatically apply consistent coding principles to source code...
Yes, coding styles are needed if there is a desire to have a homogeneous code base. Such a code base can be useful in preventing individual ownership of parts of the code base, which can cause problems when people leave the team. If you can't imagine having wildly different styles and problems understanding all of it, just look at all the different ways English text can be organized in various communications, all written but quite different such as tweets, e-mail, text messages, IM, message board posts, etc. and changes in fonts, capitalization, decorations, etc.