I have been working with Coded UI Test(CUIT) feature of VS2010 .
When recording the CodedUI framework generates a lots of hierarchical classes.
I was wondering whether coding(by hand) a CUIT would reduce the code created and would it be as optimized(in searching elements) as generated code??
Also what are the scenarios where a CUIT could be coded by hand?
CUITe (Coded UI Test enhanced) Framework is for people who prefer hand coding.
http://cuite.codeplex.com/
CUITe is a thin layer developed on top of Microsoft Visual Studio Team Test's Coded UI Test engine which helps reduce code, increases readability and maintainability, while also providing a bunch of cool features for the automation engineer.
CUITe allows you to define a much simpler Object Repository (== UIMap). Each page/window will be defined in a separate class file, and each UI control definition will be just a one liner. You can move common controls to a parent class which increases maintainability. You can also categorize the page/window definition classes into different folders as you deem fit.
I have been working on Coded UI, from my understanding recorded/generated code is too complex and difficult to maintain.
I always use hand coding, which is simple and easy to maintain.
Here is full sample hand coded UI script for Silver-light application
[TestMethod]
public void SilverlightHANDCODINGTest()
{
BrowserWindow br = BrowserWindow.Launch(#"http://localhost:1377/SilverlightApplication1TestPage.html");
UITestControl sCustom = new UITestControl(br);
sCustom.TechnologyName = "Web";
sCustom.SearchProperties.Add("ControlType", "Custom");
sCustom.SearchProperties.Add("TagName", "OBJECT");
sCustom.SearchProperties.Add("Type", "application/x-silverlight-2");
sCustom.SearchProperties.Add("TagName", "OBJECT");
// sCustom.DrawHighlight();
SilverlightControl sframe = new SilverlightControl(sCustom);
sframe.TechnologyName = "Silverlight";
sframe.SearchProperties.Add(SilverlightControl.PropertyNames.MaxDepth, "-1");
sframe.DrawHighlight();
SilverlightEdit sTextBox = new SilverlightEdit(sCustom);
sTextBox.TechnologyName = "Silverlight";
sTextBox.DrawHighlight();
Playback.Wait(2000);
sTextBox.SetProperty(SilverlightEdit.PropertyNames.Text, "Thank god");
SilverlightButton sButton = new SilverlightButton(sCustom);
sButton.TechnologyName = "Silverlight";
sButton.SearchProperties.Add(SilverlightButton.PropertyNames.DisplayText, "Button");
sButton.DrawHighlight();
Playback.Wait(2000);
Mouse.Click(sButton);
SilverlightComboBox sComboBox= new SilverlightComboBox(sCustom);
sComboBox.TechnologyName = "Silverlight";
sComboBox.DrawHighlight();
Playback.Wait(2000);
sComboBox.SetProperty(SilverlightComboBox.PropertyNames.SelectedItem,"Kishore");
}
Thanks,
You may hand write less code but its going to likely be less maintainable and more prone to breaking. You can use the partial class to effectively override the search clauses after the code has been generated.
Related
These past few days I've been thinking of a way to avoid needing to write a lot of code and still keeping a good performance for a Air desktop game I'm developing, as a hobby.
The game is a sort of vertical shooter, that consist of several entities moving and checking collision. There are plenty of different kind of units. Each frame I have something like:
entity.execute();
The simpler approach is to have all different entities to inherit the Entity class, and manually customize them all. This is slow and cumbersome, and hard to maintain. But it's fast, performance wise.
The other approach is to have only one Entity class, and just using some sort of composition to simply add "behaviors". So for example I have a master class with things like types of movements, attacks, etc, and the different entities use them.
The problem with that approach is, calling a function is slow, according to my tests, it is ~3 times slower than just having the code right there (inside execute()).
I'm in a dilemma, I can't find a way to reuse chunks of code to decorate generic Entity instances, and keep a good performance. Seems like I have to use one or the other.
I tried using [Inline], but I've read it's not a stable feature, and I didn't see any noticeable performance improvement, I didn't test it much though.
Any insight is appreciated.
Abstraction through inheritance is a good object oriented pattern, I'd argue that it is not slow or cumbersome to maintain. Separation of concerns would add clarity to classes that inherit your base Entity class; as well, reduce copied code. Interfaces would further abstract concrete types.
ActionScript does not support powerful object oriented language features that you might find in a language like C# - no abstract base class, no partial classes, limited template / generics, limited polymorphism. Composition and decorator patterns would likely force using dynamic classes, which would also slow down the runtime due to type checking.
Perhaps the greater issue is too much business logic in the Entity class. I would think some world container or controller would be responsible for collision detection.
Something you could consider is a physics engine like Box 2D.
There are ports of Box2D built with CrossBridge (formerly Alchemy, FlasCC), which is a C++ compiler for the AVM2, able to run Flash up to 10x faster through lean optimized bytecode that features high performance memory-access opcodes for Flash (known as Domain Memory).
This is how games like Angry Bots or Neverball are made.
Check out Jesse Sternberg's Box2d Flash Alchemy Port + World Construction Kit if using a AS3 physics engine sounds interesting.
There are some common approaches to speeding up the flash in game development. One of them is to avoid using display objects, in favour of simple bitmaps. In this case you have a stage as a bitmap, and keep all your game state in lightweight objects, and then just make a game state snapshot drawn into that stage bitmap data (with copyPixels) periodically (on enter frame, or on timer)
schematically: say you have a game with units
class PseudoSprite {
public var x:uint;
public var y:uint;
public var currentAnimFrame:uint;
protected var snapshotCreator:AbstractSnapshotCreator;
public function makeSnapshot():BitmapData {
return snapshotCreator.createSnapshot(currentAnimFrame);
}
....
}
class Unit extends PseudoSprite {
public var directionAngle:Number = 0;
public var speed:uint = 0;
function Unit() {
snapshotCreator = UnitSnapshotCreator.instance;
}
public function doStep():void {
x = //count x by speed and direction
y = //count y by speed and direction
animationFrame++;
}
}
class Game {
public var stage:Bitmap;
private var objects:Vector.<PseudoSprite> = new <PseudoSprite>[
new Unit(), new Unit()];
public function step() {
for each (var unit:PseudoSprite in objects) {
unit.doStep();
//draw unit.snapshot() to the stage bitmap data
}
}
}
so, you can see: you can build whole units (or all game objects) hierarchy using normal OOP, and get some suitable performance..
After some tests, I've found out that I can just do something like:
public var foo:Function;
and then when I create the entity I can:
entity.foo = myCustomFoo;
And then in the main loop I can:
entity.foo();
This is as performant as calling a native member function inside the Entity instance. Warning, don't create a getter to access your function, it becomes a lot slower.
I've been working through Julie Lerman's books on Entity Framework, and I've run into somewhat of a snag...
In "Programming Entity Framework DbContext" on page 66 Julie suggests writing a Unit Test to make sure that dynamic proxies are being created, since the requirements for getting Entity Framework to create change tracking proxies are fairly simple, but also very easy to miss.
With that being said, I followed the general structure of Julie's example to write the following test for my code:
[Test]
public void IsDynamicProxy()
{
using (var scienceFairToGoContext = new ScienceFairToGoContext())
{
var scienceFair = scienceFairToGoContext.ScienceFairs.Create();
Assert.IsTrue(scienceFair is IEntityWithChangeTracker);
}
}
When I hover over the scienceFair object its pretty obvious its a change tracking proxy
System.Data.Entity.DynamicProxies.ScienceFair_D3C57A2F699E75F716E63553D950EF7EC75F0C603F69093FCD78122CC0D6452C
...but whenever I run the unit test it always fails because "scienceFair is IEntityWithChangeTracker" always evaluates to false.
It appears as though someone else ran into this issue as well and posted it to the O'Reilly forums, but there doesn't seem to be a solution posted, nor do my Google searches return any type of answer.
I'm currently using Visual Studio 2010, EF4, NUnit, and running my tests through ReSharper. It's also worth mentioning that if run the code in a simple console application and debug it I get the same results.
Actually, it looks like I figured out the issue. While working through Julie's book, I thought it would be a good idea to have all of the entities inherit from a base class, ScienceFairToGoEntity.
It looks like I forgot to mark the 4 properties I had on the base class (InsertBy, InsertDate, UpdateBy, UpdateDate) as virtual, so the dynamic proxies were for Lazy Loading/ Relationship Fix-up and not for Change Tracking.
It's weird to find this non-working piece of code in such a good book. You can however execute you test by:
using (var scienceFairToGoContext = new ScienceFairToGoContext())
{
var scienceFair = scienceFairToGoContext.ScienceFairs.Create();
Assert.IsTrue(scienceFair.GetType().IsSubclassOf(typeof(ScienceFair)));
}
although it is less generally applicable when there are entities in inheritance hierarchies. With derived entities you'd have to use
scienceFairToGoContext.BaseEntities.Create<TDerivedEntity>()
Recently, I got started reading on BDD and TDD and I got hooked. I got lost with the amount of unorganized sources of information and different opinions of what's best and what not. At the end I settled on xBehave & xUnit. I like the fluent syntax and the ease of defining the behaviors with Fluent Assertions and Fluent Validation.
I'm also trying to implement the onion architecture with a test project I'm working on for learning. Here's my scenario: The project, to make it simple, is a product tracker. I can create products and track who owns it. I want to implement two specs:
when a new product is created without a name then an error should be displayed
when a new product is created without an owner assigned then an error should be displayed.
I created the spec which instantiated a new Product and a new ProductService which in turns creates the Product. The spec passes and the validation is occuring now the question is:
How do I test my ProductRepository class? Do I test it next or mock it and finish all specs first then come back and test repository classes?
Should I have mocked the ProductService class in the first spec?
Is that done at the unit test level? should i create a unit test class?
Wouldn't testing the repository make it an integration test?
so far, I don't have a UI and i'm writing my specs for the domain, service, and infrastructure layers.
do i need to use watin for my UI tests?
would switching to watin/specflow makes more sense and would save on efforts to have fully tested layers from top to bottom?
Here's one of the specs I worked on:
[Scenario]
public void creating_new_product_without_a_name_should_throw_error()
{
var productService = default(IProductService);
var action = default(Action);
_
.Given("a new product", () =>
productService = new ProductService() as IProductService)
.When("creating the new product without a name", () =>
action = () => productService.Create(new Product()))
.Then("it should should display an error", () =>
action.ShouldThrow<ValidationException("Name is required."));
}
Thank you for your reply in advance and, please, if you are answering this thread back up with some materials/articles/sample code on to why your suggestion would be better to follow.
It sounds like you are testing small parts and then plan to glue them together into something big. This is (IMO, againt) not TDD (and certainly not BDD): you are not letting the tests drive the design/architecture.
To start with, don't think that much about the design. Don't think onion architecture, don't think repositories, don't think services.
Start by writing a test that verifies the whole solution, from end to end. Make that test as small as possible. To start with, just verify that e.g. a label is displayed. Then write the smallest solution that you can think of to make the test pass. Then write another test and the solution for that.
After a while, have a look at the code (production, but also test) to find resposibilities. Is there an embryo of a service in there somewhere? Extract it! But don't do it prematurely. Let the code tell you what it wants to look like.
Start thinking about the domain (Product, Owner, etc) up front and include it early in your code. Wait a little longer with persistance (repositories), but not too long.
Keep testing at this level (end-to-end). Add micro tests when necessary. So my answer to the question "how do I test my ProductRepository/Service class" is a question to you: do you need to? Or is it sufficiently covered by the end-to-end tests? If not, why?
I have recently upgraded a .net1.1 solution to .net2.0.
AS this is a very heavy GUI appilcation with loads of controls and many multithreaded operations that update the GUI.
While these operations worked seamlessly in .net1.1 it is throwing up Cross Threaded Illegal operations after the upgrade.
Considering the fact that tehre are numerous grids, buttons and status labels that need to be updated via these multi threaded operations, I decided to code for checking the InvokeRequired solution, however doing that for every control would probably not be the best way to go about it.
I was wondering if you could suggest a better way of how I can go about it or propose any OOPS based class structure that I could code around to make the code look better.
Please do let me know if my question is unclear.
Thanks in advance
Here's a good article about your problem:
http://www.perceler.com/articles1.php?art=crossthreads1
The quick and dirty hack is to disable the check altogether:
static class Extensions {
public static DisableCrossThreadCheck(this Control c){
c.CheckForIllegalCrossThreadedCalls = false;
foreach(var ctl in c.Controls) {
ctl.DisableCrossThreadCheck();
}
}
}
(in your form):
this.DisableCrossThreadCheck();
C#, nUnit, and Rhino Mocks, if that turns out to be applicable.
My quest with TDD continues as I attempt to wrap tests around a complicated function. Let's say I'm coding a form that, when saved, has to also save dependent objects within the form...answers to form questions, attachments if available, and "log" entries (such as "blahblah updated the form." or "blahblah attached a file."). This save function also fires off emails to various people depending on how the state of the form changed during the save function.
This means in order to fully test out the form's save function with all of its dependencies, I have to inject five or six data providers to test out this one function and make sure everything fired off in the right way and order. This is cumbersome when writing the multiple chained constructors for the form object to insert the mocked providers. I think I'm missing something, either in the way of refactoring or simply a better way to set the mocked data providers.
Should I further study refactoring methods to see how this function can be simplified? How's the observer pattern sound, so that the dependent objects detect when the parent form is saved and handle themselves? I know that people say to split out the function so it can be tested...meaning I test out the individual save functions of each dependent object, but not the save function of the form itself, which dictates how each should save themselves in the first place?
First, if you are following TDD, then you don't wrap tests around a complicated function. You wrap the function around your tests. Actually, even that's not right. You interweave your tests and functions, writing both at almost exactly the same time, with the tests just a little ahead of the functions. See The Three Laws of TDD.
When you follow these three laws, and are diligent about refactoring, then you never wind up with "a complicated function". Rather you wind up with many, tested, simple functions.
Now, on to your point. If you already have "a complicated function" and you want to wrap tests around it then you should:
Add your mocks explicitly, instead of through DI. (e.g. something horrible like a 'test' flag and an 'if' statement that selects the mocks instead of the real objects).
Write a few tests in order to cover the basic operation of the component.
Refactor mercilessly, breaking up the complicated function into many little simple functions, while running your cobbled together tests as often as possible.
Push the 'test' flag as high as possible. As you refactor, pass your data sources down to the small simple functions. Don't let the 'test' flag infect any but the topmost function.
Rewrite tests. As you refactor, rewrite as many tests as possible to call the simple little functions instead of the big top-level function. You can pass your mocks into the simple functions from your tests.
Get rid of the 'test' flag and determine how much DI you really need. Since you have tests written at the lower levels that can insert mocks through areguments, you probably don't need to mock out many data sources at the top level anymore.
If, after all this, the DI is still cumbersome, then think about injecting a single object that holds references to all your data sources. It's always easier to inject one thing rather than many.
Use an AutoMocking container. There is one written for RhinoMocks.
Imagine you have a class with a lot of dependencies injected via constructor injection. Here's what it looks like to set it up with RhinoMocks, no AutoMocking container:
private MockRepository _mocks;
private BroadcastListViewPresenter _presenter;
private IBroadcastListView _view;
private IAddNewBroadcastEventBroker _addNewBroadcastEventBroker;
private IBroadcastService _broadcastService;
private IChannelService _channelService;
private IDeviceService _deviceService;
private IDialogFactory _dialogFactory;
private IMessageBoxService _messageBoxService;
private ITouchScreenService _touchScreenService;
private IDeviceBroadcastFactory _deviceBroadcastFactory;
private IFileBroadcastFactory _fileBroadcastFactory;
private IBroadcastServiceCallback _broadcastServiceCallback;
private IChannelServiceCallback _channelServiceCallback;
[SetUp]
public void SetUp()
{
_mocks = new MockRepository();
_view = _mocks.DynamicMock<IBroadcastListView>();
_addNewBroadcastEventBroker = _mocks.DynamicMock<IAddNewBroadcastEventBroker>();
_broadcastService = _mocks.DynamicMock<IBroadcastService>();
_channelService = _mocks.DynamicMock<IChannelService>();
_deviceService = _mocks.DynamicMock<IDeviceService>();
_dialogFactory = _mocks.DynamicMock<IDialogFactory>();
_messageBoxService = _mocks.DynamicMock<IMessageBoxService>();
_touchScreenService = _mocks.DynamicMock<ITouchScreenService>();
_deviceBroadcastFactory = _mocks.DynamicMock<IDeviceBroadcastFactory>();
_fileBroadcastFactory = _mocks.DynamicMock<IFileBroadcastFactory>();
_broadcastServiceCallback = _mocks.DynamicMock<IBroadcastServiceCallback>();
_channelServiceCallback = _mocks.DynamicMock<IChannelServiceCallback>();
_presenter = new BroadcastListViewPresenter(
_addNewBroadcastEventBroker,
_broadcastService,
_channelService,
_deviceService,
_dialogFactory,
_messageBoxService,
_touchScreenService,
_deviceBroadcastFactory,
_fileBroadcastFactory,
_broadcastServiceCallback,
_channelServiceCallback);
_presenter.View = _view;
}
Now, here's the same thing with an AutoMocking container:
private MockRepository _mocks;
private AutoMockingContainer _container;
private BroadcastListViewPresenter _presenter;
private IBroadcastListView _view;
[SetUp]
public void SetUp()
{
_mocks = new MockRepository();
_container = new AutoMockingContainer(_mocks);
_container.Initialize();
_view = _mocks.DynamicMock<IBroadcastListView>();
_presenter = _container.Create<BroadcastListViewPresenter>();
_presenter.View = _view;
}
Easier, yes?
The AutoMocking container automatically creates mocks for every dependency in the constructor, and you can access them for testing like so:
using (_mocks.Record())
{
_container.Get<IChannelService>().Expect(cs => cs.ChannelIsBroadcasting(channel)).Return(false);
_container.Get<IBroadcastService>().Expect(bs => bs.Start(8));
}
Hope that helps. I know my testing life has been made a whole lot easier with the advent of the AutoMocking container.
You're right that it can be cumbersome.
Proponent of mocking methodology would point out that the code is written improperly to being with. That is, you shouldn't be constructing dependent objects inside this method. Rather, the injection API's should have functions that create the appropriate objects.
As for mocking up 6 different objects, that's true. However, if you also were unit-testing those systems, those objects should already have mocking infrastructure you can use.
Finally, use a mocking framework that does some of the work for you.
I don't have your code, but my first reaction is that your test is trying to tell you that your object has too many collaborators. In cases like this, I always find that there's a missing construct in there that should be packaged up into a higher level structure. Using an automocking container is just muzzling the feedback you're getting from your tests. See http://www.mockobjects.com/2007/04/test-smell-bloated-constructor.html for a longer discussion.
In this context, I usually find statements along the lines of "this indicates that your object has too many dependencies" or "your object has too many collaborators" to be a fairly specious claim. Of course a MVC controller or a form is going to be calling lots of different services and objects to fulfill its duties; it is, after all, sitting at the top layer of the application. You can smoosh some of these dependencies together into higher-level objects (say, a ShippingMethodRepository and a TransitTimeCalculator get combined into a ShippingRateFinder), but this only goes so far, especially for these top-level, presentation-oriented objects. That's one less object to mock, but you've just obfuscated the actual dependencies via one layer of indirection, not actually removed them.
One blasphemous piece of advice is to say that if you are dependency injecting an object and creating an interface for it that is quite unlikely to ever change (Are you really going to drop in a new MessageBoxService while changing your code? Really?), then don't bother. That dependency is part of the expected behavior of the object and you should just test them together since the integration test is where the real business value lies.
The other blasphemous piece of advice is that I usually see little utility in unit testing MVC controllers or Windows Forms. Everytime I see someone mocking the HttpContext and testing to see if a cookie was set, I want to scream. Who cares if the AccountController set a cookie? I don't. The cookie has nothing to do with treating the controller as a black box; an integration test is what is needed to test its functionality (hmm, a call to PrivilegedArea() failed after Login() in the integration test). This way, you avoid invalidating a million useless unit tests if the format of the login cookie ever changes.
Save the unit tests for the object model, save the integration tests for the presentation layer, and avoid mock objects when possible. If mocking a particular dependency is hard, it's time to be pragmatic: just don't do the unit test and write an integration test instead and stop wasting your time.
The simple answer is that code that you are trying to test is doing too much. I think sticking to the Single Responsibility Principle might help.
The Save button method should only contain a top-level calls to delegate things to other objects. These objects can then be abstracted through interfaces. Then when you test the Save button method, you only test the interaction with mocked objects.
The next step is to write tests to these lower-level classes, but thing should get easier since you only test these in isolation. If you need a complex test setup code, this is a good indicator of a bad design (or a bad testing approach).
Recommended reading:
Clean Code: A Handbook of Agile Software Craftsmanship
Google's guide to writing testable code
Constructor DI isn't the only way to do DI. Since you're using C#, if your constructor does no significant work you could use Property DI. That simplifies things greatly in terms of your object's constructors at the expense of complexity in your function. Your function must check for the nullity of any dependent properties and throw InvalidOperation if they're null, before it begins work.
When it is hard to test something, it is usually symptom of the code quality, that the code is not testable (mentioned in this podcast, IIRC). The recommendation is to refactor the code so that the code will be easy to test. Some heuristics for deciding how to split the code into classes are the SRP and OCP. For more specific instructions, it would be necessary to see the code in question.