I am developing a web portal in asp.net 3.5 which is mainly a front end for various other links and web forms developed else where. There is not much business logic except some CRUD operations to the database and fetching data. And javascript, Jquery for user interface.
In this scenario, is unit test necessary and is it required to test the javascript also?
Unittesting is not required to get something going, but as you start testing I hope that you see that it is crucial for maintaining a large code base.
Right now your app is small, and a user can easily verify that it is working. ie. Go to a page, submit a form, make sure that the form is posting correctly, make sure that the database is saving the correct information.
As your application grows, or as you begin to build on your CRUD operations it will be crucial that they are correct and that you can test them programatically, testing your code now sounds like it would be trivial, and therefore with the effort, because of the time it saves in the future in regards to refactoring your code or hunting down bugs.
Qunit is a great simple javascript testing framework http://docs.jquery.com/QUnit
Unit test is about reducing bug and speed up development.
It can also help refactoring your code.
If you have a small project and need to go to market fast and it will have a small amount of maintenance you can avoid unit testing.
If you have only simple CRUD operations consider use scaffolding tools and simple datasource/detail view and/or Dynamic Data.
"Not much" business logic tends to grow over time. By writing unit tests to ensure that the business logic works, you'll be able to ensure it's not broken in the future, as you add more features. Unit testing also makes you write loosely-coupled code, which can have the advantageous side effect of making your code cleaner and more maintainable to begin with.
If you have a lot of jQuery and user interface operations, you can still write tests for those. For UI, look at Coded UI or WatiN. For JavaScript/jQuery, look at QUnit.
Related
As a novice to this realm, I am planning on building an mvc application. I had originally started a web forms application but decided the scalability and testability will benefit more with an mvc application. I chose to switch with the added benefit of being easier to add more features later on (instead of having code baked into web forms pages).
Now a little about my application, it is an application to stimulate an RPG class builder and moveset. In all simplicity, users can register for a class, and depending on other skills they can register for, they can see a custom move set based on these categories. The way I am envisioning it is I will be able to go back and add more classes and skills later in the database and have users register for this new content immediately once it has been added to the project.
Everything lives in normalized tables, so many joint tables do exist. For each new skill or class I add will mean a handful of tables will be added to the database. This speaks to the way the data will be stored, everything and all information about classes, user data, skills, etc will be stored in the database.
I have designed all the initial database tables I will need to have at the start, and functionality I need (a home page, view skills page, view move sets page, etc.). I am stuck at the next step; where do I go? Should I make my controllers first? Models? Views? Design my page layouts? I am asking for advice from people who have taken a similar organic approach to an mvc project. I am facing analysis paralysis on what to start on, knowing I have a lot of work ahead of me.
Thank you for taking your time to answer.
I've taken everyone's advise and am putting together a website to learn MVC: http://learnaspnetmvc.azurewebsites.net
The most important advice I can give you: just start. A big project can seem overwhelming, especially when you're looking at it like a big project. Instead, break it into small achievable tasks. Find something you can do right now, the ever-so-smallest subset of functionality, and do it. Then do the next one. And the next.
That said, I'll tell you my personal process. When I start on a new application or piece of an application, I first like to create my models. That way I can play with the interactions between them, flesh out the relationships, and think about the needs of my application in a somewhat low-pressure, easily disposable way. I also use code-first, whereas you've gone an created your database tables already. Some people prefer to do it that way. Personally, I find starting with my classes and letting those translate into an underlying data store much more organic. In a sense, it relegates the database to almost a non-existent layer. I don't have to think about what datatype things need to be, what should be indexed and what shouldn't, how querying will work, what kind of stored procedures I need, etc. Those questions have their time and place -- the nascent development stage is not that time and place. You want to give your brain a place to play with ideas, and classes are a cheap and low-friction medium. If an idea doesn't work out, throw the class away and create a new one.
Once I have my models, I like to hit my controllers next. This lets me start to see my models in action. I can play around with the actual flow of my application and see how my classes actually work. I can then make changes to my models where necessary, add additional functionality, etc. I can also start playing around with view models, and figuring out what data should or should not be passed to the view, how it will need to be displayed (will I need a drop down list for that? etc.), and such. This, then, naturally leads me into my views. Again, I'm testing my thinking. With each new layer, I'm hardening the previous by getting a better and better look at how it's working.
Each stage of this process is very liquid. Once I start working on my controllers, I will make changes to my models. Once I hit the views, the controllers will need to be adjusted and perhaps the models as well. You have to give yourself the freedom to screw up. Inevitably, you'll forget something, or design something in a bone-headed way, that you'll only see once you get deeper in. Again, that's the beauty of code-first. Up to this point, I don't even have a database, so any change I make is no big deal. I could completely destroy everything I have and go in a totally different way and I don't have to worry about altering tables, migrating data, etc.
Now, by this point my models are pretty static, and that's when I do my database creation and initial migration. Although, even now, really, only because it's required before I can actually fire this up in a browser to see my views in action. You can always do a migration later, but once you're working with something concrete, the friction starts to increase.
I'll tend to do some tweaking to my controllers and obviously my views, now that I'm seeing them live. Once I'm happy with everything, then I start looking at optimization and refactoring -- How can I make the code more effective? More readable? More efficient? I'll use a tool like Glimpse to look at my queries, render time, etc., and then make decisions about things like stored procedures and such.
Then, it's just a lot of rinse and repeat. Notice that it's all very piecemeal. I'm not building an application; I'm building a class, and then another class, and then some HTML, etc. You focus on just that next piece, that small chunk you need to move on to the next thing, and it's much less overwhelming. So, just as I began, I'll close the same: just start. Writers have a saying that the hardest thing is the first sentence. It's not because the first sentence is really that difficult; it's because once you get that, then you write the second sentence, and the third, and before you know it, you've got pages of writing. The hardest part is in the starting. Everything flows from there.
The other answers here have great advice and important nuggets of information, but I think they do you a disservice at this stage. I'm the first to advocate best practice, proper layering of your applications, etc. But, ultimately, a complete app that follows none of this is more valuable than an incomplete app that incorporates it all. Thankfully, we're working with a malleable medium -- digital text -- and not stone. You can always change things, improve things later. You can go back and separate your app out into the proper layers, create the repositories and services and other abstractions, add in the inversion of control and dependency injection, etc. Those of us who have been doing this awhile do that stuff from the start, but that's because we've been doing this awhile. We know how to do that stuff -- a lot of times we already have classes and libraries we drop in for that stuff. For someone just starting off, or for an app in its earliest nascent stage, it can be crippling, though. Instead of just developing your app, you end up spending days or weeks pouring through recommendations, practices, libraries, etc. trying to get a handle on it all, and by the end you have nothing really to show for it. Don't worry about doing things right and do something. Then, refactor until it's right.
As a first step in planning a MVC framework application, We should start with a strong Model (typical C# props). This process is going to take most of our time, based on the fact that we need to understand the business first and then the relationships between different workflows and entities. So times business models evolve as time passes. So spend qualitative time on building this layer, but not too much.
Once domain (Business) Models are ready, before we actually start coding for Repository classes, we should define our Repository Contracts which are typically Interfaces. Contracts help all parties(other components) to interact with each other in the exact same way. Then we implement contracts on the Repository component, which is just going to act like PUSH and PULL data from your persistent medium (say database). Remember repository component never going to have any idea on business logic.
Once backend has been established, We can concentrate on my actual business process implementation. We can define one more level of Contract which defines all business operations which are to be done using Model classes. This interface has been implemented by BusinessLogic Component which does the core business activity (specific methods for every business operation). This particular component will use Repository component to delegate business data to persistence medium.
With above step completed, We can easily go and build Controllers. We should be calling business logic component methods in controllers and get work done. Once controllers are done, we can define our views and other UI elements like partial views etc.
Pictorial representation of the flow is as follows -
A simple architecture (from high to low level)
Presentation Layer
Domain Logic Layer
Data Access Layer
Database
Presentation layer is MVC project containing Views, Controllers and optional View-Models.
Domain Logic Layer is Class Library project which Presentation layer will access (via DLL or Service reference). This layer contains business logic and rules for the application.
Data Access Layer may contain two sub-layers-
Repository. User repository is best practice for any long term application.
Entity Framework Model.
This will communicate with database.
Database you already have.
I would suggest reading through a book by Scott Millet, called Professional ASP.NET Design Patterns.
ISBN : 0-470292-78-4
Scott walks through what a good ASP.NET site should look like from an architectural standpoint - i.e. DataAccess layers, Business Logic layers, Presentation Layers, Domain events etc.
By following on from industry standards, you will gain a better knowledge of how to correctly put together an MVC web-site.
Hope this helps.
I would suggest you to make your MVC application around a ASP.NET Web API , since it will help, in case you go for a mobile application later.
Since you are a MVC newbie, you should download some open source projects on MVC shared by seniors in the community. Study two or three projects, and analyze a solution which will the best for you.
A quick googling will get you to some good projects.
e.g.
Making a simple application , Prodinner
After that you should also go through MSDN tutorial on MVC 5 app with SSO , to enable social logins.
I have been looking at the unit testing topic and honestly I have never yet seen it in a live application.
Im a little foggy on the subject....
A simple example is if I am populating a listbox with data, I would know through debugging if the data is being populated and if it wasnt it would probably be easy to figure out why. Futhermore I couldnt possibly put it in production if it wasnt work so, why would I need to do a unit test? I dont see the point of it.
What if you were working on an entirely different area of the site, but because of the way your code was constructed, the changes you made broke the code that fills the listbox with data? How long would it take you to discover that? Worse, what if it was someone else on the team who made such a change; someone who had no idea how the listbox-filling code worked at all? Or even someone who didn't know there was code to fill listboxes?
Unit testing gives you a set of tests that ensure you never regress and introduce bugs in areas of your program that have already been proven to work, because you run the unit tests after every change and refactoring. Unit testing lets you program without fear.
Furthermore, by designing your code to be testable, you necessarily create a loosely-coupled architecture that follows a large list of best practices, e.g. dependency injection.
The point is that by using unit tests you are sure that each class is working as intended.
What is the value of that, apart from knowing that it works under certain conditions?
When you refactor your code, change the design, rework a (supposedly) unrelated piece of code, if your tests still run correctly you know your have not broken any functionality.
Unit testing is both about ensuring that the code you write conforms to your expectations and that any changes to it still conform to them.
There're many pros and cons with using Testing. Take a look at Art Of Unit Testing somehow, this book greatly covers subjects of unit testing. Also, you can find out why you should do unit testing.
In your example, imagine you had to check populating of listbox, combobox and other data at about on 15 web pages. How much browser reload, mouse clicks, breakpoint hits and runs should you have to make to test it with debug? Many. But with unit testing, one of the core rules is that tests should be run simply, by single click. If you design unit tests correctly, you can test thousands and thousands of code with the single click
Unit testing will give you an opportunity to test your logic without hitting the sql server and firing Cassini or IIS Express. (Of course you need to implement dependency injection firstly on your main project and mock them on your test application)
Think about you have written hundreds of test methods. And you will run all the test methods in bulk. This could take a minutes and more depending on your data structure. Buy if you implement dependency injection on your project and mock them in your test, this will take quite a small time.
here is a source which you could find a good article on dependency injection : http://haacked.com/archive/2007/12/07/tdd-and-dependency-injection-with-asp.net-mvc.aspx
this my reason of using unit testing. if your project is really big enough, I think your should also consider Test-driven development (TDD)
Does data binding fit in a 3 layered architecture? Is dropping a grid-view on a web form and binding it to a LinkDataSource or SQLDataSource considered bad? The way I see it, that's the Presentation Layer talking to the Data Access Layer. I once heard a "professional developer" say never ever do this, so what's the alternative if you shouldn't?
The way you are doing is ok if it is a small project, but if you want your app. to have flexibility to support Windows/ Web in future then you must use Layers.
Please follow this link http://www.dotnetspider.com/resources/1566-n-Tier-Architecture-Asp.aspx
You should have a middle tier between Presentation and Data Access layers, the middle tier is pulled out from the presentation tier and, as its own layer, it controls an application’s functionality by performing detailed processing.
The main task of Business layer is business validation and business workflow.
When you build your business logic components into an SDK, you are effectively disconnecting it from your Web application, and any input validation that it performs. Therefore, your business logic components are the last line of defense to make sure that only valid values make it into your database.
Databinding is, of course, necessary to effectively dispay data.
Tooling is great and can boost productivity. It is equally important to understand what the tooling is generating, even at a basic level, in order to be able to effectively utilize the generated code.
The reaction you describe seems a bit extreme. If a wizard can generate some code that works for ya, then use it. If you don't understand the generated code then that is the next priority; learn about what it is doing and why. In the meantime, you have a page that people can put eyes on regardless of how it got there.
I am a bit pragmatic when it comes to tools. You do what you have to do. But, if after [insert appropriate internship length] you are still using code gen and cannot customize or fix it then you (as in the royal you, not the you you) are being lazy or stupid or both. ;-)
OT:(almost) Never say never unless you want to lessen the impact of what you are trying to communicate.
my 2 pesos.
When you're doing a small project or a prototype, go with the LINQDataSource or SQLDataSource. However, the downsides of those data sources are serious enough for you to think hard if they are appropriate. If your doing a multi-layered or multi-tear architecture, they simply don't fit. But even if your architecture isn't that strict, you should ask yourself how big this application is going to be and how likely it is going to be that you will make changes to the system in the future. How much time it is going to take you when you want to make a change to the database?
I've seen projects were the developers used those data sources, because those were the constructs that were used in those nice ASP.NET video's. However, when the projects grown from prototypes to big production applications (yes, I’ve seen it happen, the prototype seemed good enough), the lack of compile time support (your queries are defined in markup!) made it very hard to do any change to the system.
When you need to make a change to the system, that will be the time that you’ll see that the cost of the change is a magnitude bigger than the time you saved by flattering your architecture.
I have read many articles on the MVP pattern. Some folks say it is too complex and some say it's outdated. However to me it would seem like the perfect way to provide unit testing access to the UI - which is what I'm aiming to achieve.
Have you used MVP and if so what do you think?
Model View Presenter, Model View Controller, traditional three tier (UI/Business Logic/Data Storage) or virtually any other architecture that isolates the various concerns of your code help you write tests.
Often the architecture is somewhat dictated by your tool: the Asp.Net MVP tags seem to indicate that you have already made your choice there. The trickiest part to test in any configuration is the UI, because even if you create a mock UI that performs all the functions the user can... at some point you will have to render it in a browser and assure yourself that the theory is sound.
Note that this does not discount the benefits of a mock presenter UI with unit tests that exercise all the options the user will have: doing so puts you light years ahead of someone doing straight UI testing alone. On the other hand, I have yet to find a program where the UI always rendered as we expected in every browser. Finding these cases still requires human intervention (or at best something like Selenium or Test Complete once you have the initial run-throughs).
Regarding the "obsolete" aspect, I think that is a red herring. There are of course religious wars regarding architectural choices, but the reason that MVP is being used in some ASP.NET projects is that there are quite a few who felt the traditional ASP.NET stack was too tightly integrated between the UI and the Business Logic. (I'm one of them.) For small projects that tight coupling isn't that big of a deal, and contributes to the quick "bring it up and running" ability of the form designer with databinding. In large projects, the limitations of these tools show up in a hurry, and having a "middle" tier hacked back in after the fact is a challenge: one you don't have to face with MVP.
I did an ASP.NET project using MVP last year. Yes, I was able to cover more with unit testing than I could before in the webforms world, but it felt hacky. Also, try explaining what you are doing to someone else. For some reason, people have a hard time grokking it. If I had to do it over again, I'd go with the ASP.NET MVC framework, since it is officially supported with tons of documentation and buzz, and not just a hack.
Say for example you're getting a web app project that interacts with a database.
How do you start your development? Do you start by designing your database, drawing simple ERD and writting a create scripts? Do you start by designing the look of your of web app, maybe using photoshop, then create a master page for it? or do you start by designing your domain models, with minimal looks, and apply a preetier design later on?
Please share you thoughts on this... Cheers...
You start by deciding which way you start. No but really, it depends on too much factors to have a general answer. Do you develop using concepts of agile development, are there specified functional designs, did the client give you strict requirements, what is your own experience etc..
Generally we start by developing our business objects first, then creating views for them using sample data / fake databases or sometimes even plain text files. From there, we start filling in the bits and pieces. If not all requirements are set, it's best to keep the database outside your development as long as possible. That way you prevent yourself from having to change your db, sprocs and interaction with your db everytime.
I tend to do the last of those ideas, "start by designing your domain models, with minimal looks, and apply a preetier design later on" I like to make my application, of any kind, does what I want it to do before I spend time on making it look pretty.
Figure out how the users need to interact with your site first. What are they needing to achieve?
Let this define you ERD and the database model will quickly follow.
Then, when you actually start coding you'll be heading in the right direction.
Many will also say, write your Unit Tests first. It's hard to do but often worth it.
UI and DB, but it depends which one is really first. The UI is a very important thing because your customer has to work with it in the end (some say there might be developers who sometimes forget...). The database design is a very good way to put (some) structure in all the business needs which aren't always specified in a strictly and well structured way.
This is junior's experience, I've been working in development since 2004, beginning with a 4-year-apprenticeship in a development company.
Cheers,
Matthias
I start with the functional UI, moving from there to the business layer and db (usually in tandem to start with). Design is normally provided in some respect by the client, so I try to apply that early on, without letting it get in the way. I like to get the domain sorted out in one step (minor changes are acceptable later), and I create my scripts as I get to them in my code.
It sounds like a bit of a runaround, but it works for me.
I definitely start with a UI Prototype.
Clients never know what they really want untill they see it.
A simple change on a UI can translate to a dramatic change in the core components of your system. So rather let the user play with a pretty prototype until they are confident it's what they looking for, and then dive into system objects and database design.
With regards to Database and System objects, I find it difficult to decide which way to go. Going database first definitely influences my class design, so I try go object first as much as possible. It turns into a more human design IMO
Depends on the Project Id' say.
Usually it's good to have a Photoshop mockup to show your client what they're getting.
On small no-maintenance projects I try to start by modeling the database first to get a better overview on the structure. Then it's usually quite easy to create a Web Application around it.
On bigger projects I usually start by creating (basic) prototypes of critical pieces of the software. I then show those to clients and afterwards throw them away. They're just there to help me understand the upcoming challenges better.
But as said, it's a matter of taste and project.