Testing the UI has always been one of the difficulties in TDD, but I had gotten the impression that with the Razor ViewEngine in MVC3, it was possible to get the output that would be rendered for a particular view and set of inputs. You could then use string functions such as "Contains()" to verify the presence or absence of particular text that you expect to see in the output.
However, I can't seem to figure out how to do that, at least not without a LOT of mocking and scaffolding code. And I haven't been successful in finding anything on the top by Googling.
Can anyone point me to a link, or give me some pointers before I waste a couple days re-inventing the wheel by writing the scaffolding functions?
Thanks
You may find the following blog post useful. Also testing rendered HTML by views is not exactly something I would call unit test. It's more of an integration test. There are tools which are specifically designed for performing UI tests.
Related
My goal is to be able to write core testing that I can use within a unit testing framework as well as UI testing with selenium.
For simple test like:
Scenario: Add two numbers
Given I have entered 50 into the calculator
And I have entered 70 into the calculator
When I press add
Then the result should be 120
I would create both unit tests to prove that my core API would pass as well as a Selenium test that would prove my UI is doing the correct thing as well.
I briefly tried to find anyone doing something similar through Google, but couldn't find any examples. So I guess my question is, has anyone here done anything similar?
On approach I had thought of was simple adding the feature files to a project or directory and using the add existing item as link as the solution.
Update: Adding feature files to a common directory and adding them as a link appears to be working great. The feature bindings regenerates for each project the feature file was included in so I can run unit tests in one and Selenium UI tests in the other.
First, lets start with why you might want to do this. Its laziness of the good kind.
The quality that makes you go to great effort to reduce overall energy expenditure. It makes you write labor-saving programs that other people will find useful, and document what you wrote so you don't have to answer so many questions about it. Hence, the first great virtue of a programmer. Also hence, this book. See also impatience and hubris. (p.609)
Larry Wall, Programming Perl
Except it isn't, because we aren't going to reduce our overall energy expenditure.
When you are using SpecFlow, the easy part to keep up to date is the plain text. You will find yourself refactoring the [Binding]s again and again, but the scenarios tend to be quite easy to work with, and need very little revision once they have been agreed.
In addition the [Binding]s are global. Load them in from any assembly and they are available to the SpecFlow runner. In respect of what you are trying this actually makes things harder as you need to put effort in to keep the UI bindings from being mixed up with the non-UI bindings.
Also consider the way that SpecFlow actually runs the tests from feature files. It's a two stage process.
When you save the .feature file the SpecFlow VS plugin generates a .feature.cs file.
When you run your test engine (e.g. NUnit) it ignores the plain text and uses compiled code from .feature.cs
So if you start using linked .features I have no idea if the SpecFlow plugin will generate .feature.cs for both instances of the file. (If you try this please let us know)
Second lets consider the features themselves. I think you will constantly finding yourself compromising your tests to make them fit the other place they are used. Already in the example you have given you have on the screen. If you are working with just the core API then there won't be a screen, so do we change this to fit better in a non-UI scenario?
Finally you have another thing to consider, just how useful will your tests be. If you have already got a test that tests the Core API, then what will it mean to run same test via Selenium. All you will really test is the UI layer. In my current employment we have a great number of regression tests that perform this very kind of testing, running up a client that connects to a server and manipulating the UI to get the desired scenarios enacted. These are the most fragile tests we have due to their scale. They constantly break and we basically have to check our entire codebase to find the line that broke them. Often something like 10-100 of them break just for a one line change. If these tests weren't so important to the regression cycle then the effort in maintaining them would just be too much. In my own personal projects I tend to remove these tests completely and instead with UIs, I avoid testing the View layer. With WPF MVVM, I execute Commands and test for results in ViewModels. If somebody then decides the TextBox should be a ComboBox or that it will work better in mauve, then my testing is isolated.
In short, there is a reason you can't find anything about this on Google :-)
In general (see http://martinfowler.com/bliki/TestPyramid.html), one should limit the number of automated tests that test the UI directly, and prefer tests that start at the presentation layer (just below the view layer), or below.
SpecFlow is agnostic; the tests can be implemented using e.g. Selenium at the UI layer or just MSTest or NUnit at any of the layers below.
However having said that I appreciate that you will have situations where you are doing ATDD and want to implement SpecFlow scenarios to match each of the acceptance criteria. Some of the criteria will be perfectly fine to test at a lower architectural level, but one or two of them may be specific to the GUI-- for example testing Login and ensuring that the user is redirected to the home page after successful login. If using Angular2 or React routing (see https://en.wikipedia.org/wiki/Single-page_application), that redirect is likely done in the GUI layer itself.
I don't have a perfect answer yet, but as a certified SpecFlow trainer, I have a vested interest in this! The way I am currently leaning is to use a complementary tool like CucumberJS for the front-end specific tests (such as testing React router redirects) and SpecFlow for tests at lower architectural layers. Our front-end uses Node.JS/Express and our backend is .NET Core. The idea is that the front-end tests mostly use the front-end only with mocked out AJAX calls to the backend (see sinonjs), and the back-end tests use EF Core with the in-memory option (see docs.efproject.net/en/latest/providers/in-memory/. So the tests all run fast.
Of course, you still need a few tests that actually go all the way through, but those are different-- we should call those integration tests. I do not believe that acceptance tests need to be integration tests. That way, you have a suite of acceptance tests from doing ATDD, plus a relatively small set of integration tests that test all the way front-to-back. The integration tests run more slowly and require more maintenance, so you separate them out into a different part of the CI/CD build chain.
I hope this makes sense. It is not so much solving the problem as avoiding the problem.
I have used backbone boilerplate on the past
https://github.com/backbone-boilerplate/backbone-boilerplate
I want to use marionette on my next project and I have found this
https://github.com/BoilerplateMVC/Marionette-Require-Boilerplate
My question is if it's a good idea to go with the marionette boilerplate or start form scratch.
As an aside, I'd like to suggest you give Yeoman a shot for scaffolding your first Marionette app. Yeoman works via what are called "generators", and provide much more than the the above Boilerplate MVC can offer you (Chai and Sinon for testing, Bower for client-side package management, etc...). Plus, Addy Osmani, who runs backbone-boilerplates is one of the heads of the project. Check out generator-marionette here.
I haven't used BoilerPlate, but glancing through it, it certainly seems like a valid approach to writing Marionette apps. If you're just getting started it will certainly help you see how the various pieces are supposed to be used. One gripe I've got is the folder structure. I prefer to break my applications down into modules, and then add models, collections, views, etc under each module. But this will certainly get you up and running quick, and there's nothing stopping you from customizing it to suit your needs.
I agree with others here: it is a useless limitation to imitate a folder structure that follows the 'old mvc model for server-side code'. You will remain more flexible further down the road if you think of your application strictly as completely self-containing modules, i.e. they contain their own controller/router/views/collections/templates etc. You can have a separate folder structure for shared code that is not a module, although anything can be made a module :)
Regarding boilerplate code and generators: i think in the beginning you should actually NOT do it, because you won't understand what you're doing. But that's just my personal opinion.
I would like to ask if anybody knows an easy way to test Telerik controls with Watin.
We are about to start using it but before we do I wanted to see if there is anything I would need to know.
The problem that I can see we will be having is that if even smallest thing changes then all our tests will also break.
Any suggestion is greatly appreciated.
The problem that I can see we will be having is that if even smallest thing changes then all our tests will also break.
This could/will be true of all portions of your pages, including Telerik controls, depending on your test structure. Ideally, your elements will have IDs assigned and you'll use Page classes and custom control objects to remove all HTML references from your actual test code. Then if something changes on the webpage (or in a control), you verify the change is expected, then you change the WatiN page code (or control code) and re-run your tests.
The WatiN page class primer is here: http://watinandmore.blogspot.com/2009/06/introducing-page-class.html
Basically, you want to have your test code look like myPage.PickDate("3/29/2012") and not like ie.Tables[3].TableRows[2].TableCells[4].Textbox(Find.ByClass("datePicker")).TypeText("3/29/2012")
Changes can, do and should result in failing tests, however, I can attest that with a good page (or control) class setup that abstract away the HTML DOM and other specifics leaving non-HTML-filled test code, means that when changes do happen they are most often easy to get working again.
Note: Selenium also has a Page class concept, but I have not used it very much as of right now. Bottom line: If you write a lot of tests that reference the HTML DOM directly in test code, you're setting yourself up for a maintenance headache regardless of if you go with WatiN or Selenium or whatever.
Added: As to your original question: Can you work with Telerik controls in WatiN? Yes you can most likely, but depending on the control you may need to get a bit creative, possibly even calling javascript methods from within your test (page object ;) ). I've been stumped by a couple controls (non-Telerik) but most I've eventually figured out.
I realize you asked about WatiN, and I know I'll probably get downvoted into oblivion, but I might recommend Selenium instead. It seems to be more widely used and when we were evaluating the two we found Selenium easier to work with because of the Firefox plugin to record/generate the tests. This meant that our non-technical folks could set up the tests.
Since then we've successfully used Selenium to test ASP.NET sites that utilize Telerik controls. I only ran into one issue, with the RadNumericTextBoxes, which I've documented a fix for here: http://www.msigman.com/2012/02/entering-radnumerictextbox-selenium-webdriver-1-6-0/.
I'm currently in the process of writing a how-to guide for doing it: http://www.msigman.com/2012/03/automated-testing-asp-net-web-application/ (shameless plug).
You should also consider evaluating Telerik's Test Studio, our functional automation test tool. (Disclosure: I'm their evangelist for Test Studio.)
Test Studio really shines when you're working with Telerik controls. You'll get some great additional functionality around being able to dive deeper in to verifications and actions around the controls.
Even more importantly, Test Studio handles centralizing locators and pages by default, so you don't need any additional effort to best manage your UI changes.
our dev team is currently using asp.net 2.0 and after a lot of browsing and cross site referencing i found that the new in thing is the asp.net MVC but found that there's a few things that it can't do such as support asp.net controls, view state.
i'm not sure what are the other limitation besides the total change of paradigm where each page will now link to the controller which will be linked to a certain view. so in order to make the learning curve to be less steep, i wanted to pick up on MVP first as i think by just being able to take out the application and domain layer out and make them testable is already a big help to our total process without being too much of a hassle.
after more browsing around, i find that the ndoc is a bit outdated now and is being replaced by sandcastle which has an additional add in call docproject so that should covers the auto generation of the documentation in the codes very well.
and to handle the acceptance test, i find this tool call fitnesse which is based on FIT which should helps.
so being totally new to all of this, i'm wondering if this is a good process overall to have this tool in to cover our team's development process. and if there's other sample/resources/framework out there which covers all of these steps and does a better job than trying to piece in the gap by using several tools, i.e. a framework?
basically my question is is my
overall process above well covered
by the tools that i've researched?
and is there a better way to do the
asp.net tdd + auto doc generation +
acceptance testing?
any advice/feedback is appreciated.
thanks!! :)
Yes, ASP.NET MVC with NUnit and FitNesse are reasonable choices for an 'agile' approach. Just not sure where auto-doc generation fits into this. Will anyone read this generated documentation or will they just look at the code? If you haven't read it yet, get Robert Martin's 'Clean Code' for some good tips on how to make code maintainable and understandable without lots of comments and generated documents.
Recently, I thought about how can I improve the quality of the projects, by using Continuous checking of xHTML source at Continuous Integration machine.
Look, we have a project
http://sourceforge.net/projects/jtidy - jTidy
JTidy is a Java port of HTML Tidy, a HTML syntax checker and pretty printer.
It can validate the xHTML through a command-line interface. Or this tool can be extended in the way we need, because all source code are open.
We can overwrite every Selenium validation method, such as assertTextPresent, or any other, so it will be calling the jTidy(by providing current state's HTML source), and if some errors or warnings will occur - it can be saved to Continuous Integration machine build's logs - so any project's related can see this info.
We can not to rewrite all the Selenium methods, to integrate this call on every step, but to make this calls where we want(after DOM manupulations).
Yes, we can use W3C markup validators for our sites, but there isn't any possibility to validate not initial state of page's source with this validators. After page creation, there might be lots of DOM manipulations which can produce markup errors/warnings - we can find it immediately with this scheme.
One of the benefits of using Continuous integration is that you have quick feedback from code - how it integrates with existing code base, test whether unit and functional tests pass. Why not to get an additional useful info, such as instant xHTML markup validation status. The earlier we identify the problem, the easier to fix it.
I haven't found anything on this theme in google yet.
And want to know, what do you think about this idea?
Seems like a worthwhile idea.
I've done two similar things with CI before:
I've used Ant's XMLValidate task to validate static xhtml files as part of the build process
I've used httpunit to pull pages that I then parsed as xml
But the idea of tying into Selenium to validate the content inherently during a functional test run is novel to me.
I think, that idea is brilliant but it is very hard to implement it from scratch.
But this idea is like evolution of build/quality validation process, so it will be released as ready-to-use tool with documentation someday.
Good idea! - in fact I just had exactly the same idea and was just checking to see if anyone had done it before - argh! Looks like you beat me to it :)
I was thinking along the lines of capturing and auto-submitting each page hit by selenium to the w3c HTML and CSS validtors (by file rather than link so state is held) - failing on any errors. I like the jtidy idea though.
Great in principle, but I'm not quite sure how to call it from Selenium. I'd love to see documentation explaining how to run it from Selenese, or from PHPUnit.