Coming from Java programming, I'm used to the general Main<->Test Maven-setup for a project.
Whenever there's a new build, all tests will be run by Maven/Junit and I get feedback about them.
I've been looking around and I can't find an analogue way for ASP.NET and Nunit.
Am I forced to put my UnitTest-classes in the APP_Code folder?
What's the general way to do this? Are there any recommendations for continuous integration?
The best way to architect a TDD-able web app is to put all your code in codebehinds; no inline ASP. Make the controls in the codebehind classes public, and develop your logical operations (bind/unbind, maybe) via TDD. As long as you can see the control and its children from outside the assembly, the unit tests can go anywhere.
Also consider an MVC setup; doesn't have to be the actual MVC framework of .NET, but if you strip down the codebehind to the absolute bare minimum, and perform all your logic in a controller class, then you can provide a mock page/codebehind for unit-testing the controller logic.
Related
I wanted to build a VB.net web application using MS Visual Studio 2015. Someone suggested me to create a Web API instead of MVC project if i'm also planning to create a mobile app later on. I may use angularjs in my project so controllers will surely be used, so what should i choose when creating the project in the first place?
Because when i created a web project: File=>New Project=>ASP.net Web Application=>Empty..there are no folders for Controllers, Model, etc. Do i have to create a Controller folder on my own?
Or should i do this: File=>New Project=>ASP.net Web Application=>Web API..? sorry if its a silly question. its just that i'm afraid that if i chose the wrong project now, it'll affect the development later on.
Answer to your question mainly depends on your choice and needs,
for example
In Case of an empty project as name defines you will have nothing else web.config.
Benefits of it:
here you can define, design your own structure. you can either make
it simple 3 tier or you can make it WEBAPI application. it's all up
to you.
however in the case of choosing Webapi template you will have a prebuilt structure which can help you out for initial understanding
https://docs.asp.net/en/latest/tutorials/first-web-api.html
benefits of it
You will get predefine template and structure.
you can utilize of webapi's which further isolate you backend logic from the frontend.
as you are also planning to create the mobile app. and using front end as angular, so in that case, webapi may come handy.
as the whole world is moving towards webapi, so i will recommend you to use it. please refer https://blogs.msdn.microsoft.com/martinkearn/2015/01/05/introduction-to-rest-and-net-web-api/
so down the line it all depend on you if you want to build you application for the stretch and take full control of it regarding structuring backend etc.. then go with empty else go with Microsoft pre-define template
Thanks,
Ajay Kotnala
Why should I use ASP.NET MVC with TDD?
Which are the advantage of TDD? Why it is suitable for MVC to use this kind of approach?
ASP.NET MVC offers an alternative to traditional WebForms development. It gives a clear separation of concerns in the application which makes code easier to test. In contrast to WebForms, in ASP.NET MVC infrastructure classes such as HttpContext are abstracted and could be mocked in unit tests to simulate request handling. You also have much more control over the generated HTML which is a good thing in case you want to comply with standards.
Due to the separation TDD could be applied. In this iterative process, unit tests are written to validate the code against a list of specifications. In the first stages of development writing unit tests might seem to slow down the process but as the code grows its benefits become clearer as you no longer need manually test every aspect of the application once you modify or refactor something.
Testablity and TDD
Compared to ASP.NET testing (unit testing) is much, much easier.
Plus on a side note, I enjoy having full control over the HTML output to the users browser. Rather than the mess that ASP.NET auto generates for you.
ASP.NET MVC is a joy to use in comparison.
They are a natural combination :)
ASP.NET WebForms is not friendly to TDD. MVC makes it much easier.
Asp.net mvc with TDD:
This walkthrough shows you how to develop an ASP.NET MVC application in Visual Studio using the test-driven development (TDD) approach. MVC was designed to enable testability without requiring dependencies on a Web server (IIS), on a database, or on external classes. (This is in contrast to unit tests for Web Forms pages, which require a Web server.)
In this walkthrough, you will create tests for an MVC controller before you implement the controller functionality. You can write tests before you have a controller. The advantage is that compiler errors in your unit tests are then a first-level form of unit-test failure. The emphasis is on how to design the intent of the controller by writing unit tests before implementing the controller itself, which is an important aspect of the TDD philosophy.
Test-driven development:
Test-driven development (TDD) attempts to resolve this problem and produce higher quality, well-tested code by putting the cart before the horse and writing the tests before we write the code. One of the core practices of Extreme Programming (XP), TDD is acquiring a strong following in the Java community, but very little has been written about doing it in .NET
**one advantage according to my experience is that:
When You are refactoring code ..it will TDD help to find impact of change on other modules or Codes.
Other advantage is if you are developing application with TDD with proper test methods application is more stable(stable means minimum bugs) than simple development.
SOLID is a set of design principles that we constantly think about and try to follow when writing good production code.
SOLID stands for (Single responsibility principle, Open-closed principle, Liskov substitution, Interface segregation and Dependency Injection).
What makes TDD great when writing an ASP.NET project (or any projects for that matter) is that by following TDD you automatically create code that follows the SOLID principles.
SOLID code will make your code easily changeable, less brittle, easy to maintain and flexible. = Great code.
I have an ASP.NET web app which is growing.
It is done in traditional web forms. While I would like to convert it WCSF to improve testability, this is time-prohibitive. I have taken the action to only make method calls in ASPX code behind which call the appropriate methods in the classes in App_Code so the spaghetti code is gone, which is good.
What else could I do to improve testability without any fundamental rewrite?
Thanks
Is this a Web Site project? I find Web Applications are more structured and easier to maintain. I'm not sure if they are more testable. Then do use namespaces where a web site does not.
Have you considered using a UI pattern such as MVP? You also might get partial coverage with creating interfaces for your code-behinds and testing against the interface. Watch out for hidden side-effects (changing the state of a dropdown within a method, it hidden behavior).
A book I found helpful was 'Working Effectively with Legacy Code' by Michael Feathers.
I'm working on an ASP.Net website along with a supporting Class Library for my Business Logic, Data Access code, etc.
I'm EXTREMELY new and unfamiliar with the Unity Framework and Dependency Injection as a whole. However, I've managed to get it working by following the source code for the ASP.NET 3.5 Portal Starter Kit on codeplex. But herein lies the problem:
The Class Library is setup with Unity and several of my classes have [Dependency] attributes on their properties (I'm exclusively using property setter injections for this). However, the Global.asax is telling Unity how to handle the injections....in the Class Library.
Is this best practice or should the Class Library be handle it's own injections so that I can re-use the library with other websites, webapps or applications? If that is indeed the case, where would the injection code go in this instance?
I'm not sure how clear the question is. Please let me know if I need to explain more.
Though not familiar with Unity (StructureMap user) The final mappings should live in the consuming application. You can have the dll you are using define those mappings, but you also want to be able to override them when needed. Like say you need an instance of IFoo, and you have one mapped in your Class Library, but you've added a new one to use that just lives in the website. Having the mappings defined in the site allows you to keep things loosely coupled, or else why are you using a DI container?
Personally I try and code things to facilitate an IOC container but never will try and force an IOC container into a project.
My solution breakdown goes roughly:
(Each one of these are projects).
Project.Domain
Project.Persistence.Implementation
Project.Services.Implementation
Project.DIInjectionRegistration
Project.ASPNetMVCFrontEnd (I use MVC, but it doesn't matter).
I try to maintain strict boundaries about projects references. The actual frontend project cannot contain any *.Implementation projects directly. (The *.implementation projects contain the actual implementations of the interfaces in domain in this case). So the ASPNetMVCFrontEnd has references to the Domain and the DIInjectionWhatever and to my DI container.
In the Project.DIInjectionWhatever I tie all the pieces together. So this project has all the references to the implementations and to the DI framework. It contains the code that does the registering of components. Autofac lets me breakdown component registration easily, so that's why I took this approach.
In the example here I don't have any references to the container in my implementation projects. There's nothing wrong with it, and if your implementation requires it, then go ahead.
I want to build an ASP.NET MVC application with Boo instead of C#. If you know the steps to configure this type of project setup, I'd be interested to know what I need to do.
The MVC project setup is no problem. What I'm trying to figure out how to configure the pages and project to switch to use the Boo language and compiler.
So there are two levels of "work with Boo". One would be all the code (namely, the Controllers), and the other would be the views.
For the code, I assume Boo compiles to standard .NET assemblies, so simply properly following the naming conventions using by ASP.NET MVC should allow you to write Controllers. You will probably need to start with a C# or VB version of the MVC web application project template and port some of the boilerplate code over into Boo to get the solution entirely in Boo (I presume Boo supports Web Application projects?).
The other half is views. Someone will need to port the Brail view engine over to the ASP.NET MVC view engine system. This may already be done, but I don't know for sure. If it's not, then this is probably a significant amount of work to be done.
Probably the best place to get answers to these kinds of questions is the MvcContrib community on CodePlex.
The Brail view engine has been implemented to be used in ASP.NET MVC. The MvcContrib project implemented the code. The source code is located on Google Code.
As far as the controllers, I really am not sure. I am not that familiar with Boo. I know a lot of developers use it for configuration instead of using xml for instance. My tips would be, if Boo can inherit off the Controller base class and you stick to the naming conventions, you should be alright. If you vary off the naming conventions, well you would need to implement your own IControllerFactory to instantiate the boo controllers as the requests come in.
I have been following the ASP.NET MVC bits since the first CTP and through that whole time, I have not seen somebody use Boo to code with. I think you will be the first to try to accomplish this.