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
Has anyone worked at a large company, or on a very large project, that successfully used unit testing?
Our current database has ~300 tables, with ~100 aggregate roots. Overall there are ~4000 columns, and we'll have ~2 Million lines of code when complete. I was wondering - do companies with databases of this size (or much larger) actually go through the effort to Mock/Stub their domain objects for testing? It's been two years since I worked in a large company, but at the time all large applications were tested via integration tests. Unit testing was generally frowned upon if it required much set up.
I'm beginning to feel like Unit testing is a waste of time for anything but static methods, as many our test methods take just as long or longer to write than the actual code ... in particular, the setup/arrange steps. To make things worse, one of our developers keeps quoting how Unit Testing and Agile methods was such an abject failure on Kent Beck's Chrysler project ... and that it's just not a methodology that scales well.
Any references or experiences would be great. Management likes the idea of Unit Testing, but if they see the amount of extra code we're writing (and our frustration) they'd be happy to back down.
I've seen TDD work very well on large projects, especially to help us get a legacy code base under control. I've also seen Agile work at a large scale, though just doing Agile practices alone isn't sufficient I think. Richard Durnall wrote a great post about how things break in a company as Agile gains ground. I suspect Lean may be a better fit at higher levels in an organisation. Certainly if the company culture isn't a good match for Agile by the time it starts being used across multiple projects, it won't work (but neither will anything else; you end up with a company that can't respond effectively to change either way).
Anyway, back to TDD... Testing stand-alone units of code can sometimes be tricky, and if there's a big data-driven domain object involved I frequently don't mock it. Instead I use a builder pattern to make it easy to set that domain object up in the right way.
If the domain object has complex behaviour, I might mock that so that it behaves predictably.
For me, the purpose of writing unit tests is not really for regression testing. It helps me think about the behaviour of the code, its responsibilities and how it uses other pieces of code to help it do what it does. It provides documentation for other developers, and helps me keep my design clean. I think of them as examples of how you can use a piece of code, why it's valuable and the kind of behaviour you can expect from it.
By thinking of them this way I tend to write tests which make the code easy and safe to change, rather than pinning it down so nobody can break it. I've found that focusing on mocking everything out, especially domain objects, can cause quite brittle tests.
The purpose of TDD is not testing. If you want to test something you can get a tester to look at it manually. The only reason that testers can't do that every time is because we keep changing the code, so the purpose of TDD is to make the code easy to change. If your TDD isn't making things easier for you, find a different way to do it.
I've had some good experiences with mock objects and unit testing in projects where there was a lot of upfront design and a comfortable timeline to work with -- unfortunately that is often a luxury that most companies won't afford to take a risk on. GTD and GTDF methodologies really don't help the problem either, as they put developers on a release treadmill.
The big problem with unit tests are that if you don't buy-in from a whole team what happens is one developer looks at the code with rose colored glasses (and through no fault of their own) implements only the happy path tests which are what they can think of. Unit tests don't always get kept up as well as they should because corner cases slip by, and not everyone drinks the Kool-Aid. Testing is a very different mindset than coming up with the algorithms, and many developers really just don't know how think that way.
When iterations and development cycles are tight, I find myself gaining more confidence in the code quality by relying on static analysis tools and complexity tools. (FindBugs, PMD,Clang llvm etc) Even if they are in areas that you can't directly address, you can flag them as landmines and help better determine risk in implementing new features in that area.
If you find that mocking/stubbing is painfull and takes a long time then you probably have a design that is not made for unit-testing. And then you either refactor or live with it.
I would refactor.
I have a large application and see no trouble in writting unit-tests and when I do I know it's time to refactor.
Of course ther is nothing wrong with integration test. I actualy have those too to test the DAL or other parts of the application.
All the automated test should form a whole, unittest are just a part of those.
Yes they do. Quite extensively.
The hard part is getting the discipline in place to write clean code - and (the even harder part) the discipline to chip away at bad code by refactoring as you go.
I've worked in one of the world's biggest banks on a project that has been used from New York, London, Paris and Tokyo. It used mocks very well and through a lot of discipline we had pretty clean code.
I doubt that mocks are the problem - they're just a fairly simple tool. If you've got to rely on them super-heavily, say it looks like you need mocks of mocks returning mocks - then something has gone wrong with the test or the code...
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 6 years ago.
Improve this question
I have a test suite which works against a dedicated copy of the real database. The application creates a complex object by filling it from the database and it would be a lot of work do create one "manually" or mocking one to bring it to a valid state. So I ran a database query from the tests in order to have a valid object (not to verify that I integrate with the database correctly). It was working blazing fast. Especially after the first call MSSQL was caching it and the query ran in less than 1 ms.
Are there any arguments why I should avoid doing this? If it's because speed when the database is on the same network it's working fast? It seems that most literature out there wouldn't recommend doing this - but why?
EDIT - To answer my own question: "unit tests" means that each test is autonomous, if you touch the database one test could modify it and affect another test. Even though transactions can solve it, it's still not quite in the "spirit" of "unit tests" and make them a bit cumbersome. So this should be avoided but not under all circumstances, if I have no choice I'll access the database in transaction which will make sure it won't affect other tests.
This seems to be a principle some people follow - that you should never hit the database - but my experience is that sometimes, trying too hard to avoid the database creates these giant tests, over-use of mocks, or a strange and brittle data access interface. Search about for test-induced design damage for more on this idea.
For my part, I'm happy to access a database as part of tests. You can often do write tests if you can wrap the whole test in a transaction, too.
We split up our tests in unit tests and integration tests/dlls. The unit tests cannot go to the db, the integration tests can.
Keep in mind that having a lot of integration tests can seriously slow your build. I can run all my unit tests in minutes while running the integration tests take over an hour.
You have to define for yourself WHAT you want to test? Do you want a test that simply checks if your API does what it should? Then you can mock even that single database-entity from your tests and test if your code goes right. Need an integration-test including database-traffic, network, ... ? Test your real-world scenarios including the code that is neccessary to get and manage your entities. So it depends on what you want to test and what you expect from those tests.
Considering the DB-performance should play no effect on this decission as you cannot relate on any DB-specific optimization in your tests. What happens when you decide to change the DBMS to something without this kind of optimization? Than your tests will fail which is doubtfully what you want. Performance should never affect what to test, however it might play a rule on how to do so.
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
I am working for a consulting company that develops a lot of Add-Ons for SAP Business One using .NET. I want to introduce TDD (or at least some good unit testing practices) to the company to increase code quality. Here's the problem.
SAP provides a COM object (called Company) that lets you interact with the data in SAP. Company is an interface, so it can be mocked, but the amount of Mocking that would have to be done to get a single test to run is huge! I've tried it out with a few tests, and although they work, I really had to have a good understanding of the internals of the unit that I was testing, in order to create tests that passed. I feel that this very much defeats the purpose of the unit tests (I'm testing the internals as opposed to the interface).
Currently, through the use of dependency injection, I've created a Mock Company object that returns some Mock Documents that will sometimes return Mock values based on different circumstances, just to get the tests to run. Is there a better way? Has anyone been able to effectively unit test code that heavily depends on some external library? Especially when the results of the tests should be some change to that mocked object? (Say, when the add-on runs, the Mock Company object's SaveDocument function should be called with this Mock document).
I know this may be a strange question, but the fact of the matter is that in order to get these unit tests to run well, I feel like the only option to me is to create a really...reaally large mock that handles multiple Mock Documents, knows when to give the documents at the right time, and a lot of other things. It'd be essentially mocking out all of SAP. I don't know if there's some other best practice that others do in these cases.
Thanks in advance!
EDIT: Carl Manaster:
You're probably right. I think the problem is that most of the existing code base is very procedural. A lot of Windows services with a Run() method. I can definitely see how, if the project was structured a bit better, tests could be made with a lot more ease.
But let's say that the company can't invest in refactoring all of these existing projects. Should I just abandon the idea of unit testing these things?
If your methods are short enough, you should be able to mock only the interactions with one entity (Company), without interacting with the entities it returns. What you need is for your method to call (let's say) company.getDocument(). If your method under test has further interactions with the returned document at that point, split out that code, so that you can test that code's interactions with a (mocked) Document, without worrying about the Company in that test. It sounds as though your methods are currently much too long and involved for this kind of approach, but if you whittle away at them to the point where testing one method simply verifies that company.getDocument was called, you will find it much easier to test, much easier to work with, and ultimately much easier to understand.
Update
To your question of whether you should abandon the idea of unit testing: Do you want it to work? Do you have changes to make to the code? If the answers are (as I would assume) affirmative, then you should probably persevere. You don't have to test everything - but test what you're changing. You don't have to refactor everything - but refactor what you're working on so it's easier to test and easier to change. That "whittling away" that I mentioned: do that in service of solving the problems you have at the moment with your code base; over time you will find the code that most needed the tests has been tested - and it's a lot easier to work with because it's well tested and better factored.
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 am looking for honest / constructive feedback.
I hear a lot of my peers who have been using .NET for a while now, say how easily they built their GUI interfaces. On closer inspection they have used 3rd party tools such as Infragistics.
As a new .NET programmer (certified I may add), I wanted to know if anyone has actually created interfaces using nothing but what ever happens to be available by default with the framework...
I am guessing it shouldn't be too difficult to create a good, aethestic looking GUI without using 3rd party addons.
Yes We've done it (windows).
Depends on where you put the emphasis in your guess. No its not TOO difficult, but it's definitely not easy, unless your requirements are truly trivial, as opposed to apparently trivial.
All depends on what you need / want to do. My advice don't tell your boss, this will be easy, well not unless you want help getting out of the door for the last time.
For instance take a straight textbox.
They want to enter currency in it.
Multiple rounding algorithms.
Enter raw value display formatted, Currency symbol, thousand
separators.
Optional pounds or pence.
Optional blank or zero
Optional treatment of negatives.
Optional display formatting of negatives.
Alignment on decimal point.
Auto change of font on resizing.
And break none of the standard behaviours.
Trust me not simple at all. Especially if you do something Infragistics did not, and go for a good developer interface as well as the end user behaviours.
Not trying to put you off. It's challenging and rewarding, but when you have the entire application stuck behind some irritating bug in the UI, bosses lose patience real quick and you haven't got that get out of jail free card in shrugging and saying that's how X works.
NB just buying a suite won't fix all these problems, you can spend a lot of time producing a totally crap UI with them as well, just you don't have to write the code...
The answer to that is a lot of hard work. :(
Can your current suite be upgraded?
If you have the source could it be fixed, if you had the source and it's been twiddled with, are those "improvements" interfering?
Needs some hard-headed realistic analysis this. Which components are broke? How much are they used? How much of the extra behaviour in the suite do you really need.
Most important, how good is your separation of concerns in the current code, and how comprehensive both unit tests and automation tests.
Would compatibility mode sort it out?
Need to get to a point where the number of questions doesn't significantly out weigh the number of answers.
I've been where you are though it was another suite in another environment. The people looking for the cheap, quick and painless way of dealing with a mess like this were hugely disappointed, but it can be attacked in parts as long as everybody takes a heavy dose of pragmatism.
As a for instance,
Someone had bought a windows component that looked like a html link, and was heavily dependent on File associations and API calls. It was very visible and all over the place, I knocked up a much better and far less fragile one in a few days, swapped it in, a lot of perceived problems disappeared, confidence increased, and the remaining problems started to look less horrible.
Think of it like going into triage mode on bugs at the end of a struggling release.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I recently came up with an idea for a simulation/strategy game. I've been sketching out a lot of my ideas on paper about the game mechanics as well as have a few of the basic classes and objects working. (I'm writing this in C# using XNA).
One thing that is painfully obvious to me though is that I am not a graphic artist and trying to get anything graphical programmed right now is frustrating me. One thought that came to mind was trying to make the entire game work off the text console first. I remember spending hundreds of hours playing Zork and Hack as a kid and the majority of my game element ideas don't require real time sprite animations to work.
So my question to the community here is should I try to maintain my enthusiasm for concept by focusing on getting it to simply work in a text base mode first and then regroup on giving it a pretty graphical interface?
OR
Tackle the graphical interface hill at the same time I'm trying to flush out my idea?
During the course of writing this question I think I answered it for myself, but I would love to hear thoughts from people.
I think you have the right idea based on your description of the game. If you separate your concerns then you can implement a lot of the business logic first. Think of it like an MVC application. You can leave your view to be implemented later; just provide a layer that interfaces with your business logic, that your view can use.
This way it doesn't matter what your view is (text-based or graphics). You can just pass metadata up to the view, and the view will decide how to render it.
So I would say that your idea is good. Start off with the business logic and a text-based view. That way you can get your concepts and ideas fleshed out and also decide what kind of data to pass up to the view. Remember one thing though - you have to be extremely careful at this stage to not let assumptions about the view leak into your business layer. So you should code your business layer and associated interface to the view, as if you have no idea what the view is going to be. What I mean is, since you are starting with a text-based interface, don't make coding decisions that tie you to that particular implementation.
Once you have everything fleshed out, you can start learning graphics and slowly start your graphics layer.
Of course, this approach (MVC) may not work in all situations, especially when your view is time critical. For more information, take a look at these Stackoverflow questions:
Is the MVC design pattern used in commercial computer games.
Best practices when Designing iPhone Game with MVC
Game framework architecture - view components or MVC
I just want to be clear that I'm not advocating an MVC pattern for your game -- I just want to emphasize separation of concern so that it is easy for you to swap your view without doing significant refactoring.
A game is a complicated project which can be divided into many compartments. These may be actual module (e.g., a GUI renderer or a communications manager), or they may be more theoretical or logical, such as the "game design".
While all of these parts work together - preferably in harmony - to bring out the actual game, each of them also stands by itself. As such, it is always a good direction to divide & conquer. If you are confident about your idea, then by all means go ahead and implement it in the simplest form possible, which would probably be a console application.
However, you do need to keep in mind that while you can start by developing each module separately, eventually you will need to take into account how these parts will work together. This will inherently impact your modules design. For example, you may find out that your game logic is working beautifully, but you have no way of letting the user actually doing a certain step in terms of UI. Playability is one of the most important features of a game, and your UI may even dictate some game logic. This concept contradicts the golden rule of separating the UI from the logic - but like I stated, games are complicated, and for the final product you often find yourself bending some rules. Games are different than other projects - scalability is not an issue. Maintainability is important but will be sacrificed if you need that extra CPU juice... and so on.
Make an UI. Keep the graphics simple (Paint) and focus on usability. Then release your game as open source and someone else will create nice graphics and a cool UI.
My advice: almost no software nowadays can be done single-handed.
Try to sketch out your ideas, post somewhere, find more people interested, assemble a group, and get your hands dirty.
If your idea is truly good, you'll find more team members that can fill your lack of expertise on the other areas needed.
You can try to find people on the web, starting something like an open-source project, or you can try finding an investor, that can inject money on your business and you'll be able to hire specialized people.
If I were you, I would create a text-based command line interface first. Then, if you decide to make an actual GUI, you can just have the GUI automate the command line game, so you don't have to write the game logic twice. Many tools will use this approach. Someone will create, for example, a command line defragmentation tool and then someone will create a GUI "wrapper" for the tool. Sort of like what Nethack did.
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 am not the only programmer, but I'm the only .NET developer, everyone else works with Perl, Ext JS, and related technologies. I'm primarily self taught, using Codeproject heavily to learn new techniques.
Without any mentors at my company specifically knowledgeable in .NET, I'm unsure whether classes, or online tutorials, books, or perhaps some other avenue might be most effective at helping me to become a better developer.
My goal, optimistically, is to become a developer capable of managing the next .NET developer we hire, or at least to integrate well with him/her.
I'm currently taking on the task of documenting my programs in such a way as to receive review from the more experienced developers at my company regardless of them not knowing .NET, and I expect this will be rather general, but hopefully still beneficial.
Does anyone have suggestions or advice for how to most effectively learn good practices without direct oversight?
Without mentors around, there are several things you can do to improve your skills:
Take classes...especially if your employer will pay for them.
Read books. They're the next best thing to a class.
Read developer blogs. They may not teach you best practices, but they'll keep you abreast of what's new in the development world. That'll help you keep from falling behind.
Courtesy of the Community Listen to Podcasts (Hanselminutes, Stackoverflow, etc.) and watch Screencasts (Dimecasts has tons of good content).
Participate in the community. We may seem harsh at times, but you'll hear the most about best practices, coding techniques, design patterns, etc. and different ways to apply everything.
I have always worked like that. My ways to improve are:
Reading high-quality blogs
Applying what these high-quality blogs recommend (whenever it fits your project and when time allows, of course)
Reading high-quality open source project's source code
Writing as much code as you can, always keeping in mind what you've learned and always trying to raise the quality bar. Practice does not make perfect. Only perfect practice makes perfect.
Keep an eye on stuff that's unrelated to your own line of work. For example, if your main job is coding ASP.NET in C#, read stuff about functional programming, F#, Haskell, other web frameworks like django, Ruby on Rails, etc. I'm not saying that you learn them, just see how things can be done differently. It will broaden your perspective.
When you gain some self-confidence: contribute to open source projects, write a blog.
About books: IMHO the books that are highly-technical (i.e. "Buzzword 2.0 in Action!") aren't worth your time. Everything happens so fast that they'll probably become obsolete 6 months after their release. The only books worth buying are those that deal with the underlying CS or architecture issues.
About classes: it's very hard to find high-quality non-university classes that aren't a waste of time/money. Most of the time you can learn faster by yourself. (UPDATE: fast-forward to 2013, MOOCs are an amazing, high-quality, free learning resource)
Also be wary of codeproject, there are lots of articles there with errors and/or general bad advice.
I am in the same situation you are in. I learn mostly from
previous projects/mistakes, especially when you take over an old project from someone else (50%)
google (25%)
forum/stackoverflow (25%)
Change employers. I'm not trying to be a jerk, seriously. The most growth your going to have as a developer is by working every day with someone significantly better than you.
Join some OSS project which works with .NET to get feedback on your code from experienced .NET developers. In addition looking at other people's code is a great way to learn new things - just as you have been doing. I also agree with Justin also that reading blogs like Eric Lippert's is very rewarding
Take advantage of the chance to learn the languages and technologies being used by by your colleagues.
They'll introduce you not just to syntax, but more importantly to techniques, idioms, and paradigms that you won't find in .Net, but that will challenge you to think about how you could apply or build those thing in .Net, or why .Net doesn't have or shouldn't use those things.
Why is Perl weakly typed (or is it)? What's Perl better at than .Net? What is .Net great at the Perl is just terrible at? Why do these differences exist? How might you implement a Perl interpreter in .Net? Why might you want to?
Why's everything in a JavaScript a hash? How does .Net class inheritance compare to JavaScript prototypes? Are JavaScript's first-class functions a great tool or a source of obscurantist abuse, compared to .Net's strongly and statically typed classes?
What are the fundamental data structures in each language? For each language, why are those types fundamental to that language? What were the different design decisions (or lack of decisions) that motivated and informed each language's design and implementation? Can you discern any common "ancestral" languages among the languages used at your workplace? Why don't we have "One Language To Rule Them All"? Should we?
Finally, excellence at any one language is really great to have, but unless you're sitting on that language's Standard Committee or writing compilers/interpreters for that language, a broader knowledge of the underlying algorithms and data structures and patterns that are common across languages is probably more important to your development as a programmer -- and certainly to managing programmers, if that's your goal.
Look for local .NET user groups. In most cities, you are likely to find at least one. User groups are a great place to develop contacts, ask questions about the technology and basically get answers to problems you may be experiencing. If there are no user groups in your area, try looking online.
If you are free to choose how you develop, and you get new projects fairly often, pick a new technology you're not familiar with to use on each project. Of course, do your research first and make sure it makes sense for the project.
At my last company, I was pretty free to use whatever I wanted as long as it made sense and worked. I always tried to use something new on each project. The last project I worked on, I used NHibernate. No one told me to learn NHibernate, but I took it upon myself to use it to expand my knowledge. Of course, I made sure NHibernate was acceptable first.
The best way to learn something is to use it. Classes and books are good, but nothing will make it stick more than using it in a real project.
My goal, optimistically, is to become
a developer capable of managing the
next .NET developer we hire ...
In that case, you should be looking to expand or improve your people/project management skills as well as developing your technical programming and design skills in your chosen technology.
I also subscribe to the view that it is not a good idea to focus too much on a particular technology; e.g. .NET. Too much specialization tends to limit your career prospects.
A year ago I was pretty much in the same boat and it's interesting when I look back at the things I wasn't so good at. Awareness of the technology you are using is an important one, many people have suggested reading books/blogs etc which are good.
One thing that may help you, is to look at the MCTS material, starting with a foundation exam (I'm working toward 70-536 .NET 2.0 Framework exam) to make sure you have a good base. One of the advantages of this is one that it is credited by Microsoft so you can add it to your CV for the future and it gives you a more structured approach than just reading books.
Secondly read up on design practises, or even design principles (such as Gang Of Four). Do your best to not cut corners, and develop your code in the best re-usable way. This keeps you thinking about design and maintainability which is extremely important.
Finally I'd probably suggest trying to ensure you're not doing the same thing over and over. Don't just work with databases, or UI's etc... Try to get a mixture of things to try new techniques and learn new stuff.