Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
Just attended a presentation where a testing company stated that V-model testing can be used in an Agile development team developing with java and c#.
I would prefer testdriven development and automation of acceptance testing before V-model testing.
Not sure if V-model testing and Agile testing can be considered the same.
Looking for your testing experience or opinions about using v-model testing in Agile teams.
If you are using V-model testing in agile, how do you do it (or is it not making sense)?
Update: Thoughtworks presentation (Agile vs v model)
V-Model is widely used at my company. I must add that, IMHO, there are better development models out there, but V-Model can still be effectively used when developing large-scale systems where you are NOT using iterative development.
Still, it's my idea that test-driven development can still be applied to V-Model, as part of the unit testing phase and even on integration testing phase, as long as you can automate that as part of the development cycle.
V-Model, however, sees system testing as a test that occurs after the development of the product is considered complete, so test-driven development doesn't apply. Sure you can automatize it through the use of tools, scripts or programs, but you are no longer developing your code. On System Tests you no longer care about the code, only about specifications. This happens so because your tests units could be incomplete.
Finally, user acceptance, in V-Model, shouldn't be completely automatized, because it's when the final user looks at the system and decides whether it adheres to the requirements or not. Of course the user will have a script on his hands in order to know what he/she should be testing, and in case of, let's say, batch systems, there will be an supply of data, but in no way should a script determine the success of this phase.
But let's get back to the question. What I just said is that TDD and automation can be used as the implementation of testing phases in V-Model. So, if you can use V-Model testing with Agile development, as presentation you saw affirmed, then I can also use TDD and automation techniques.
However, I'm not sure you would want to. I don't know how one could apply V-Model to Agile or if it would be coherent, since V-Model is not agile.
Test driven development is about specification, not test. This is not antagonist with a V approach.
On the other side, V-model implies a single long cycle of development. This is antagonist with an agile approach.
V model testing doesn't really fit in with the ethos of agile development. So in short, while it is feasible that it could be done, it would compromise the nature of the agile process.
One of the important features of agile is the ability to adapt to change. The V model doesn't really support it well.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I'm writing some test code for testing an ASP.NET MVC web application with Castle Windsor DI, Domain Driven Design (Application/Domain Services, Repository, Domain Model), NHibernate, and (most likely) MOQ for mocking. The possibilities of what can be tested are endless as basically everything can be tested.
Some possibilities are for example:
Ensure Castle Windsor configuration will work (Test some conventions)
Business logic (Inside an Entity, or Domain Service)
Other things can be tested such as the controller actions etc.
There are quite a few things (so many layers - Controllers, Services, Repositories) which hardly seem worth any effort to test as they are quite simple in general.
With a smaller application it isn't very clear what could have the most benefit yet, but it will grow and the same patterns will be used on more complex applications.
For those with similar applications, what are you unit testing?
Domain models and Application services are first citizens for unit tests if you don't have enough time or new to writing tests. These tests cover the most important part(application services for flow control and domain models for business rules). When I start to learn writing tests(don't know TDD at that time), they're the only part I test.
Then everything could be tested after adopting tdd. You'll need integration tests covering persistence, messaging and other integration points(mostly for testing configurations).
The best answer for "what to unit test" question is ... everything - according to TDD :)
However, ensuring that properly configured components will work well together is rather a part of Integration Testing or Smoke Testing.
The suggested scenario in TDD is to write tests in parallel with the code, so both codes grow simultaneously. Your problem probably lies within the fact that you already have the code, and don't have the unit tests. In such situation there are two possibilities:
1) Your components are well separated. Then you can write unit tests for public interface of each component, aiming to achieve high coverage (measured with some coverage tool).
2) Your components are tangled together. Then I'd suggest writing as much integration tests as you can, also aiming for high coverage. This will be harder than in case 1), so best to test most typical and crucial scenarios, and then refactor the code to loose some coupling, and then proceed with step 1).
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 2 years ago.
Improve this question
Hello I am interested in hearing objective responses in what should a beginner dedicate his or her time into:
ASP.NET, Visual Studio, C#, IIS, Team Foundation Server?
or
Python, Django, PyCharm?
These are just some criteria that I am interested in:
Easy to start out with.
Good documentation.
Highly-scalable.
Big Career opportunities.
Feel free to post your personal opinion on this matter or if you've had an experience with both ASP.NET and Django.
C# or java will pay the bills, python will be way more fun
This is a big question, I'll give only several points according to your interests:
In general, Django is easier to start than ASP.NET. Simplicity is one of rules in Python's Zen. Also Django explicitly shows you all control flow, so you can understand internals of framework very quickly. On the other hand, guys from Microsoft did their best to make web development similar to development of desktop applications. ASP tries to erase borders between server and client sides. I can't say with confidence, if it is good or bad idea, but I know that at some moment you'll have to understand difference between them anyway.
Both. Python community provides tons of documentation, and Django official documentation is always up-to-date. Django is popular in community, but ASP is corporationally promoted and supported. In general Django has more tutorials and ASP has more books about it. Books are more complete, but they are really big.
None of them. They both are primarily view technologies, and for scalability you'll need some heavy server side technologies. Nevertheless, if it's all about supporting thousands of concurrent users (and not some computationally intensive applications), both technologies work well. See this for some good examples in Django and this to take a point of ASP.NET scalability possibilities.
It heavily depends on your region and current situation. I can only say that ASP.NET is used in large companies, and Django is for small companies and freelance. For more information see your region vacancies.
I've been an ASP.NET programmer for a few years, and I think it's pretty easy to get into. The downsides here are that Microsoft products (TFS in particular) are expensive. Of course, my experiences have been directly related to that -- I've never tried Python in any regard -- so I can only offer my perspectives as an ASP.NET programmer.
There are a lot of people who would (accurately) tell you that the page lifecycle in ASP.NET is a gigantic pain in the ass, and that's true too. I personally don't use the server-side part of ASP.NET very often anymore because juggling the lifecycle just leads to messy code and built-in obtuseness. That said, it's really easy to integrate ASP.NET WebServices with jQuery and JavaScript.
My experiences with IIS have been pretty good as well, although I can't speak to its problems in more complex environments.
I do love TFS, though. In particular, if you're working as a part of a team and need to get user bug reports or enhancement requests, there's a lot of great built-in integration. However, configuring and maintaining TFS is a full-time job in and of itself if you're a part of a development team in a corporation.
All that said, I'm not sure it makes much sense to limit yourself to two core languages and then ask about career opportunities. These are going to vary from place to place. I don't see many Python positions where I live, and there were a lot of MS/C#/ASP.NET positions available when I was looking for a job.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I've been developing with C#/ASP.NET (and now ASP.NET MVC) for several years. I'm 100% self taught, and I'd like to believe I try to do what's best practice, but...
My question is, what do you think separates self taught developers from trained professional developers? What techniques, in C#, would you consider advanced - that self taught developers may not have picked up on their own?
Update:
I love the responses so far, thank you. Here's a bit of clarification for what I was looking for.
What C# features/techniques/usage do you think that professional developers use that self-taught may not (usually self-taught go with what's easiest to learn first)?
lets say,
from 100 developers, 5 are highly motivated by their passion for technology and self teach them what they think is the best thing to know.
the other 95 developers will be trained by those 5 developers and what they think that are the best techniques.
Best practices/techniques?:
IMO these are ways, to develop a software product, known to lead to a performant and maintainable system - and these ways come with the experience from the development of a real software system and not one from a training course.
// Latter edit:
//Short on topic answer
-> C# best practices in a corporate enviroment?
They use frameworks similar with CSLA http://www.lhotka.net/cslanet/ , or they make or use frameworks which has at the basis concepts like: Business Entities, Business Components or Business Objects.
More sepecific on C# -> nothing just go with the conventions :).
//Long boring answer:
-- My background
I worked with ASP.Net MVC 1.0 in a company with 170-200 employees and now I'm working in the same company but just on ASP.Net, we pretty much do ERPs and big web apps like that.
I self taught myself ASP.Net MVC and when I worked on ASP.Net MVC I had to do small trainings for the other memebers in my team which didn't had experience with it.
By my logic,
A selft thaught is a developer who works on frelanching projects or in a startup.
A corporate trained developer is a person who works in a corporation with 100 - 50000 employees and does java/.net in well controlled and planned corporate enviroment.
Because even if you are self thaught, in a corporation you will end up beeing trained.
//Technology
A self thaught thinks more about the technology itself, not carring about: "will this thing be easy to maintain after 3 years, is this good for an enterprise client... and so on.
The thing is that a self thaught will always teach himself the latest technology while a corporate trained developer usually is trained on the "mature technology" which is "risc free" and everybody in the corporation board thinks that this will stay here for at least 10 years...
Therefor because of that an responsible PM in a corporation will enforce their devs to use in the project an Inversion of Control Framework - one that is mature :P.
While a self thaught, because he didn't went through big projects, will be tempted to just code.
I go on the logic that a big project needs over 50 devs and that is kindoff corporationish.
Remeber if you are self thaught and work in a corporation you will get trained...
//Project and scaling thinking
A corportate developer doesn't have to think, he has to know very well the flow and the practicess that are thought in the corporation.
A corporate PM will always think about scalability and to have a smooth architecture, while
a self taught person should think like this:
http://www.aorsi.com/wb/startups_die_for_not_having_customers_so_stop_thinking_about_how_to_scale/
//A little bit of coding practicess:
Corporation:
We want to develop X and Y, good let's build a framework around the solution, maybe something like CSLA, Business Entities or worst case Business Components, we create 3-tieers and split the project on tasks.
In a corporate enviroment you want to do this because you are always thinking about maintenance, which is kindoff interesting because you will reach the sentence -> "we need developer A, B, C, to train the newcomers about the framework" - so you still have a little bit off overhead with the training...
Self thaught developer:
Dives directly into the tehnology.
//Coding practicess are the same for both self thaught and coroporate trained:
For example in ASP.Net MVC
Keep your controlles very clean and small in size.
TDD is more and more frecvent used in corporations and by self thaught devs.
I am also a self-taught developer, and have moved into a company that is largely made up of "qualified" developers. I don't deny that many of my colleagues are the best people I have worked with, but being self taught has also given me a drive to improve myself constantly to try and keep at their level.
From my experience, qualified developers tend to have better grasp of process. They have good structured methods of design and implementation. The qualified developers usually also have more confidence to chose and idea and stick with it, drawing on the experience from their qualification as well as their own experience. That isn't to say that being a self-taught developer is a bad thing. Self-taught developers that I have met tend to be well read, and good at trying different solutions to find the most appropriate.
As for what techniques in C# specifically a trained professional might have that a self-taught person may not, I don't think there are really any. However the trained / qualified developer may have a better understanding of things like design patterns, data structures or development methodologies, but a good self-taught developer will be able to learn these as well.
The main pattern showing up in the differences between self-taught and trained developers is around awareness of theory, technology options available and importantly relevant technology and industry standards. That's not to say a self-taught developer cannot match a trained developer, it's just a trend. Examples of each specific to C# and ASP.NET may include understanding OO concepts and how they apply in different scenarios, application of design patterns, understanding of TCP/IP and HTTP at a protocol level, and knowledge of PCI-DSS and its implications for web application development.
self-taughts would..
be self-motivated to software development.
be passionate about their job.
be not complaining.
have far better knowledge of how web and http works [since you asked asp.net mvc].
not first solve the problem, rather first find the right problem.
eventually become ninja-developers.
All developers are self-taught developers. Training courses are an introduction. The most, and best, training comes from experience, and any professional developer must be prepared to be continuously "in training". In fact, many job postings explicitly list self-learning as an expectation.
It's unreasonable to expect schools to stay current with the various changing technologies used in the real world, so they rightly tend to focus on concepts. But even patterns and methodologies aren't static. What is the "best" pattern could depend on the language, or the framework, or the project itself. Again, developers must be adaptable and open to learning new concepts or even reevaluating concepts they were taught in school.
As for C#, general object-oriented programming practices apply. I don't think C# itself is generally taught in schools, but language-specific features are usually just convenience layers over patterns that are already used in general. For example, properties are just pairs of methods, and events are just an implementation of the observer pattern. As with all languages, you should follow the conventions used by its community, such as identifier naming rules.
If you're worried you might be overlooking some topics that are covered by professional training, you could look through complete lectures from top universities at YouTube EDU:
http://www.youtube.com/education?category=University/Engineering/Computer%20Science
One can self teach himself programming languages, algorithms, OO principles and patterns, XP and group based developing, usability principles and testing, etc.
But it's most probable that he will only learn about programming languages.
Even in universities some people learn only about programming languages.
You can teach anyone to be trained professional developer giving to them some templates and patterns etc. but you cant teach anyone to be passion for technology and self learning.
Self learning and motivation only the key to workmanship.
e.g if we compare developers with food =>
Trained professional developer - unnatural fast food (MacDonald's etc)
Self taught developers - excellent natural well cooked home food.
Now feeling the difference?
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
I have been learning about TDD and BDD and using this as much as I can at work but in an environment that really isn't agile.
I want to try it out properly on a pet project at home. So, going with the agile approach, and the principle of having working software, what should I write first? Should I create some forms first (this will be WPF / WinForms), linked to some dummy model? Or should I work ground-up. Any advice would be great!
EDIT
I know that I will be writing tests first. The question is at a higher level. Should I aim to put a working model and business layer together first or start with a form and a dummy model.
You are looking at it from a wrong perspective.
You are separating the application into components horizontally - UI component, backend component and so on.
Instead, you should look at it vertically - what are the different features - it could be login/logout, display list of users, display some other data and so on. Sort those slices into a priority order - which one needs to be done first, which needs to be done second and so on.
Then you concentrate on the most important slice until it works, whatever it takes - if it needs UI you add UI, if it needs backend logic you add backend logic and so on. Only after it is finished and fully working you go back to your list of slices, reevalute them, select the most important one again and concentrate on it.
Repeat until you are done.
This is basically what always working software means.
It allows you to stop at any point and say - this is good enough, and ship it.
If you work horizontally you will not have anything working until you finish all the work.
I usually start with the feature and area that is most important. Take a look at this SO answer.
If you want to do TDD/BDD you do start with tests.
In my humble opinion it is always good to start with model tests unless they are totally based on framework's functionality.
As for checking Controller/View part I prefer to have 'blackbox' tests which check if i get response I expect from an http request (for web applications). It allows to remove brittleness from the tests.
Even if I do full TDD test I often throw tests away if they are about nitty gritty parts of implementation, because otherwise very when refactor implementation at the end user experience is the same, so my application works fine, but I am spending hours fixing the tests. I don't to train myself to avoid refactoring just because I know the pain it would give by redoing a large body of testing code.
I would advice to test only things that really matter to you and ignore the rest till it bites.
When I do get a bug from something I was ignoring, I do write a test to document the bug even it it is about low level implementation.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
I'm involved in a project where we are using a Continuous Integration server and NUnit for unit testing and integration testing.
A customer asked us the other day if we were writting the tests before the code... Well, were are not doing it this way always. Specially when there are complex technology issues that we would like to test to understand the problem and the possible solution first.
I would like to know if we could still considered our development process as following Agile Development, say it to customers and don't lie.
I think you are mixing up things here.
Test-Driven-Development (TDD) does not necessarily mean you are using an agile approach. Surely, it is a best practice that many of us who do agile use, but TDD can also be used in a Waterfall process, replacing/supplementing the specification.
Continous-Integration on its own means having the code your team produces integrated on an at least daily basis. This does not only force every member of the team having to merge/checkin continously, but also assures you actually can do a release of every build.The unified build process forces you to overcome the "works on my machine syndrom". Because you could do a release everyday this supports an agile process, even though it is not absolutely necessary in the strict sense.
Using tests and integrating them into the build process is a way to enrich your buildprocess with automated Quality Assurance and deepen the level on which integration (integrity) is actually tested.
As long as you are developing in small iterations, focus on getting a working product rather than on getting extensive documentation, and the customer is continuosly involved in the project, it is agile development. Unit testing, TDD and integration testing are of course good and very advisable practices, but they do not decide whether your project is agile or not.
In the absence of Automated tests, CI only verifies that the code under source control is maintained in a compilable state between revisions and that the single-step build works properly. While this is useful, it isn't as useful as the automatic verification that the correctness of the code has been maintained between revisions.
With that said, I'd rather have some verification of code between check-ins than none. I'd rather have partial code coverage or an incomplete set of functional tests than nothing. Or worse.