General statistics
List of Youtube channels
Youtube commenter search
Distinguished comments
About

Ton Bong
Modern Software Engineering
comments

Comments by "Ton Bong" (@tongobong1) on "Modern Software Engineering" channel.

Today IT labour shortage is just a myth. In reality there is a large surplus and this is why there is a long hiring process. There was a shortage more than a year ago.
160
@luke5100 developer shortage is just a myth from the past.
17
Exactly. Currently there is a huge surplus of developers looking for a job. In good times there usually is a shortage. Good times ended a year ago.
15
The demand is way down and the supply of developers looking for a job is way up.
9
Martin Fowler if you are reading this please STOP THE LONDON STYLE UNIT TEST MADNESS. These tests are terrible for projects and they are costing Europe billions! Save the Europe from London style unit tests by promoting classical unit tests!
6
@ContinuousDelivery I am a senior developer and after applying for more than 100 contracting jobs in Germany and Austria I got ZERO interviews mostly because my German is basic. I usually work as a contractor in those countries and language wasn't an issue until the bad times came for IT industry. Today it is very hard to get a job even for experienced developers.
6
I would love to see a video about when to delete unit tests that are no longer needed because we have more useful unit tests that test more code.
5
Just stay away from mocking as much as possible!
5
@GdeVseSvobodnyeNiki same with me 15 years ago in Slovenia. Austrian client was paying my company 9k per moth for me and I got just 1.6k gross salary per month. I wanted just 50 € more to stay and my boss refused so I gladly left the company hearing how angry was the customer on my boss for letting me go off the project. Many eastern European companies are extremely greedy. This is why I prefer to work as contractor in Germany and Austria.
5
The problem with TDD is this: 'To a man with a hammer, everything looks like a nail'. TDD is a great tool if you know when to use it and also when you should NOT use it.
4
Gregor said: "Any line of code that is not deployed is cost" so what about the code of unit tests then? I think many unit tests are useful but there are also unit tests that are not worth the cost of having them and we should delete them right? Especially we should delete many London style unit tests because those hard to understand unit tests are terrible for projects right?
4
I see you are on the right path to understand unit tests. One of two main goals of unit tests is to create documentation in code. Good documentation is easy to understand. Mocks are making unit tests hard to understand on top of coupling with implementation code and giving us false negatives when we keep the functionality and change the internal implementation. Usually mocking makes sense only when calling outside the process like calls to database, filesystem or remote resources but never use mocking libraries to write those mocks. The other way to test those calls is by using integration tests. Unit in "classical" style is unit of functionality. Unit can be small (single method call) or large (many objects collaborating to provide functionality) but it is always ONE functionality. If you want to test more than one functionality in one test then create an integration test.
4
@Tony-dp1rl Great question. It is interesting that even Martin Fowler admitted in this video that he is not doing TDD as much as he "should". I wish David would ask him why not. There are many good reasons why we don't use TDD and I wish we would discus them more.
4
Writing tests is EASY once you STOP COMPLICATING about writing tests. Just write some simple straightforward tests and you are good to go and forget about writing tests for every edge condition that can occur.
4
Yes but it is very common in iterative development that we don't understand the feature at first. This is why we implement something we think customer wants and get the feedback from him ASAP so we can improve and show him again and again.... until he is satisfied with the result.
4
@brookestephen Today it is hard to get an IT job there even if your German is great. In good times it was easy even if you didn't know a single word in German. Wait for good times and go there. I propose Vienna because it is such an interesting city. I stayed for more than a year there and I would love to get another job there.
4
@beowulf_of_wall_st yes it is common for a company to lose competent people because it is not firing the incompetent.
3
I wouldn't underestimate Elon Musk after we can see his work at Tesla and SpaceX. I believe Elon saw that the whole working culture at Twitter is bad - lazy and the best way to change it is to fire most of them and then hire new engineers that will improve the working culture.
3
I totally agree with Dave Farley that "quality in modern systems is our ability to change them". On the other hand London style unit tests use many mocks implemented by hacky mock libraries that are hard to understand and they easily break when changing the internal implementation despite the functionality remains the same. London style unit tests make the system much harder to change yet Dave still thinks London style unit tests are useful. What do you think?
3
Most experienced developers with 20+ years of programming experience that I know don't know how to write a good unit test. All those that write London style unit tests don't know how to write a good unit test.
3
You don't understand the agile process. Agile means that you don't know exactly what a customer wants so you create a small upgrade and show it to customer and he will give you more input so you can change it until the customer is satisfied with the result. Only then you can create a test that will preserve the functionality after many small changes of the code in the future cycles. The main benefit of writing tests is to protect the current functionality from future upgrades.
3
Yes I think interviews should be more like conversations between two engineers about common problems we face and not so much about answering questions about some details that we can find the correct answer on google in 5 minutes.
3
@mamneo2 great! Can you please tell me where is such shortage of IT workers? I will try to find a job there maybe even your company can hire me.
3
The best thing to do with London style unit test is to delete them. It is better to have no unit tests than to have bad unit test that London style promotes.
3
@PavelHenkin but you can develop outside-in/top-down with classical unit tests too and the end result are easy to understand tests without mocks and easy to change implementation of existing functionality without breaking the unit test. Unit tests should only fail when functionality changes and not when internal implementation changes while functionality stays the same.
3
Great explanation why we should use the TDD. TDD is really a great tool. Now it would be great to hear when we should NOT use the TDD. You should ask Martin Fowler why he is not using TDD every time he is writing code.
2
Yes those class tests are "London" style unit tests where you should mock every call outside the class under test. They are just terrible. You should use the classical style unit tests instead.
2
Usually you write full test before the first line of production code and you don't change the test only production code when you write more full tests.
2
I am a bit disappointed at you Dave that after all this time you still didn't find out that London style unit tests are just terrible for projects. Unit as you said is not a class and it is also not a piece or pieces of code. Unit is a unit of functionality and it can be implemented by many objects of different classes or just by a single function. London style is a great example of how NOT to do unit tests. Tests know way too much about internal implementation of a public interface that users can see. You mentioned the injected objects but what about objects that are internally created by a class whose functionality we want to test? Should we mock all those internal objects and should unit tests know about them? Of course not. The question you should ask is what is the purpose of unit tests. 1.Unit tests are protecting the implemented functionality from bugs that can appear after we change the code - extend it or refactor/redesign it. The last thing we want is to get false failures of unit tests because we changed the internal implementation while the final functionality works as before - as expected. 2. The other purpose of unit tests is to get the documentation in code from which we can learn how to use the classes. It is much harder to understand unit tests that have mocks and even worse those that use mock libraries than just plain straightforward unit tests. So London style unit tests fail at achieving both goals. I can tell you that the best programmers at the top software companies like Google and Facebook don't write London style unit test - only "classical" unit test with very few mocks - less than 5% of unit tests have test doubles. Finally if there is piece of software that is hard to test with classical unit tests like web app that is using database then this is a sign of a bad design. We should separate business logic from database access right? We don't need mocks to test business logic that is properly separated from database or filesystem...
2
@MrAntice the truth is quite different. It is a dirty business where most companies that offer programming are trying to earn as much as possible by selling cheap inexperienced developers as expensive highly experienced.
2
I believe we should increase the flexibility and complexity of design/architecture only when we really need it and never upfront.
2
SOLID is important if job interviewer is a highly experienced software developer. If manager is doing the job interview then looking confident is more important than what you say. LOL!
2
@aakarshan4644 the important part is also understanding the wars between different opinions about unit testing and styles, using TDD or not, agile vs waterfall... and stay away from that topics because you never know what are interviewer's preferences. Once a manager on a job interview asked me if I am one of those that like to write unit tests - he clearly hated unit tests. Since technical lead was also present and he clearly liked unit tests I answered very diplomatically that unit tests are sometimes useful but this was not good enough answer for manager that clearly wanted to hear that I don't like unit tests... LOL Beside can you imagine that there are many experienced developers in Europe that are still writing London style unit tests? That they still didn't realized how terrible is to mock out everything that is not a part of the class under test?
2
Yes there are several rugs that we should pull from programmers. One rug is trying to use TDD everywhere. The other is mocking everything outside the class under unit test and another rug is using mock libraries... I believe good unit tests are the next step in making system that are easy to change. Unfortunately right now 90% of programmers don't know how to write a good suite of good unit tests.
2
Exactly. Once I worked in a company that paid me a low rate from the start with a promise that after 6 months they will pay me competitive rate if I will fulfill their expectations in the first 6 months. After 6 months they were satisfied with me so they hired me for indefinitely and they raised my salary just for about 4% so it was still far from what I could get elsewhere. This made me "drunk" so I didn't want to work hard anymore and eventually I left the company on bad terms. LOL!
2
If I were Pope I would make Giordano Bruno a saint.
2
@NicodemusT sometimes you need a mock to create a test but you should consider changing the design so you don't need the mock to test the functionality. Example: instead of loading data from injected object you could load data and send it as a parameter to method that you want to test.
2
@dflor003 mocks are terrible and you shouldn't use them to mock services.
2
@rmworkemail6507 We write requirements when doing agile. They are just a bit different than in waterfall process. They are not set in stone from the start - just for the next sprint and then we can change them...
2
@powerswitchfailure Dave is doing London-style and I try to convince him against this nonsense. I am baffled how many otherwise experienced programmers just don't get how terrible is London-style.
2
@rhornjr Yes I am suspicious to those who know exact definitions. I want them to explain the principles by their own words and I also like to ask them about disadvantages. Usually when they know disadvantages they have a lot of experience. So what are disadvantages of doing TDD? LOL!
2
@bobbycrosby9765 Mocking sometimes is not London. London is mocking everything.
2
@pauligrossinoz OMG you did a huge mistake with that senior dev. He was afraid of you because you were too good so he didn't want to be your boss because you might take his position someday. The truth about interviews is that knowledge is just part of equation. I had some very strange interviews in my life. Once a senior developer at interview was excited to give me the job when I said unit testing is useful while I made the manager angry because he thought unit tests are waste of time. The most important is to find out who is the boss in the interview and make him happy because he will decide who will get the job.
2
@harryd5571 depends on money. If they pay well then I can work with that too. I work as a contractor and all I care is my hourly rate that is much much higher than the rate of full time employees. I don't mind programming silly things on bad projects if they pay me well for that.
2
@barneylaurance1865 so Dave can ask Martin Fowler why he didn't use TDD everywhere when he was still working as a programmer.
2
TDD is also overrated because in reality there are many cases where it is not useful and yet TDD gurus want you to use TDD everywhere. They are so silly.
2
@milandalosur1850 good point but it depends on location. In my country Slovenia the pay is not much better than the pay of a waiter. In Germany and Austria they still pay better but since now it is hard to get a job there wages are slowly going down. My hourly rate is 30% lower than it was before the IT "recession" and I still cannot get a job.
2
The shortage of jobs and higher supply of developers looking for a job is caused by many factors. #1 higher interest rates, #2 lower growth of economy, #3 energy crisis because of war between Russia and Ukraine, #4 many developers from Russia and Ukraine are looking for a job in USA and EU
2
You can test IO with integration tests and keep it separated from business logic that you can test with unit tests without the need to mock anything - if you have a good design.
2
Yes the strict TDD sometimes feels so silly... You should skip the silly parts and write a test for the basic functionality that makes sense first. When you implement the functionality so the test passes then you should write tests for edge cases and fix the implementation so they all pass.
2
@PavelHenkin Then don't mock interactions between objects unless they go outside the process like calls to IO, database, network...
2
@GdeVseSvobodnyeNiki it depends on where you are looking for a job and also when. Today it is hard everywhere but in Germany and Austria they prefer experienced developers over inexperienced. In the eastern Europe they prefer inexperienced students over experienced because they don't care much about the quality and they just want to earn more by paying inexperienced less. It is a dirty market in eastern Europe so you should go to west or to USA where they care and pay for quality.
2
But it is also weirdly that even Martin Fowler sometimes forgets to use the TDD as he just admitted or maybe it is not so weirdly. It seems like sometimes is more useful to implement somethin without TDD.
2
EXACTLY! London style unit tests are class tests testing every class in total isolation from other classes using mocks so they are just terrible. I am baffled how many smart programmers like Dave Farley still think London style tests are useful. It is time to REJECT those crazy tests!
2
@ModernSoftwareEngineeringYT there are many other cases where TDD is not that useful. 1. when visual inspection makes more sense than automatic tests - the sizes of interface windows, graphics... 2. when there are no exact results - random results, random terrain generators in games... 3. when tweaking parameters to balance game or to improve AI or similar cases...
1
@ModernSoftwareEngineeringYT yes there are parts of terrain generation that you can develop by TDD but how can you write tests that can check if the generated terrain is fine?
1
@fringefringe7282 interesting thought. The nature of software development is a bit different from other engineering in that our customers don't know what they really want from software so we are exploring options until we find solutions that satisfy customer needs. In most engineering professions customers know very well what they want from engineers. Waterfall prohibited changing requirements so customers got solutions that were far from what they really wanted. On the other hand change of requirements is in the core of Agile development. I agree that managers focused only on immediate business value can harm projects because as system grows we need to improve the internal structure - refactor and redesign it so we can easily extend it with more functionality and this is even more important than adding business value.
1
I don't think several thousand unit tests at Tweeter is too few at all since Amazon AWS has around 5 thousand unit tests and Hibernate around 10 thousand unit tests. Americans are mostly writing classical unit tests so they rarely mock out other classes or use mocking frameworks. 60 thousand tests are way too many for smaller project than Twitter and this might be the result of London style of writing unit tests. London style tests are bad for projects.
1
@ModernSoftwareEngineeringYT few years ago I worked for a company that is one of the top 10 largest financial companies in Europe on its main project with huge code base. The company has revenue of more than 100 billion per year and the project was the key for successful competition in the financial market. Unfortunately the project had mostly London style unit tests and they were a mess. Most developers were confused by them and didn't like to write them. The core of the code base was old, full of hacks and dirty. Nobody was brave enough to touch it also because it was protected by London style unit tests that knew way too much about implementation so any refactoring would mean also repairing hard to read and understand unit tests. It was easier to create a hack than to change the core. Since developers didn't like to write unit tests they kept too much of business logic in GUI classes instead of extract it into business classes because GUI classes were not required to have unit tests. We also didn't read unit tests to understand classes under tests because it was so hard to understand them. The only exception was a programmer who was regarded there as guru and he once told me that I should also mock all classes from java standard library. Then I started to think that the whole London style is just madness. Since then I studied open source github projects from top American companies like Google, Amazon, Facebook and Red Hat and I found that none of them are using London style tests. Their tests are straightforward classical unit tests with very few mocks - maybe 1% of tests contain mocks. It is time to stop the London style madness! I know you are British and maybe you like those tests because of the name "London" but honestly you shouldn't mix patriotism with engineering. You should critically reevaluate unit testing and I hope you can come out with the right conclusion about unit tests. Also "Tell don't ask" principle is not that great according to Martin Fowler. Good unit tests are very useful to protect the code from regression and as documentation in code so I hope influencers like yourself will save European projects from lousy London style unit tests that are more harmful to projects than useful.
1
@ModernSoftwareEngineeringYT London style unit tests are actually class tests because everything outside the class is mocked out. Yes they were written after the fact. TDD is not London style. You can write classical or London style unit test when using TDD. The only good thing about TDD using London style tests is the ability to implement classes top down but cost to do it are terrible London style unit tests and bad design that is just silly with chains of objects. We can get far better design with classical TDD like Kent Beck described in his book. We also get far simpler unit tests without mocks and we need less unit tests to cover the production code. The only drawback is that it is harder to implement it top down. Maybe you think that your code is well designed and clean but if it contains so many unit tests and if most of them contain mocks and many of them are just silly tests that check nothing useful then your opinion is clearly biased and you should rethink how much better design and tests you would get if you were using TDD with classical unit tests. I hope you will recognize this and you will start promoting the right way to write unit tests in Europe and to save us from the London style nightmare. Only brave developer influencer can do it. Are you brave enough?
1
It is wrong to differentiate tests by sizes - the number of lines they test. We should differentiate by speed and how independent they are from other tests. Unit tests should be very fast and totally independent from other tests so we can run them in paralel mode while integration tests can be slow and independent so we can only run them is sequence. This is the proper differentiation between unit and integration tests so please stop writing silly small unit tests that test just few lines of code.
1
You just wrote a bad unit test. Good unit test has well defined inputs and outputs.
1
@gJonii Usually every time it feels silly to write a test before production code, when implementing GUI, random data generators, when you don't know exactly what you want to achieve just approximately, for data definition, getters and setters...
1
@gJonii Sometimes the design is just not an issue so I don't need the TDD to create a good public design. Example is just a simple method call that implements something complex using many private methods... I have many implementation ideas and the fastest way to test them is to just look manually at the results I get. Writing unit tests for all temporary tests seems like wasting time and it is rather annoying to change focus from test to production code and back. Only when I have a stable implementation I create a unit test or few of them that protect functionality and then I can refactor and extend it further. This is the case when TDD is not that useful.
1
@thomasmoores3512 if you think you can do TDD the proper way then please tell me how many unit test you deleted while doing TDD. Those that keep all or almost all unit tests while doing TDD don't know how to do TDD the proper way.
1
WARNING the proper way to do TDD is to DELETE many unit tests that are fully covered by larger tests. If you don't delete many "small" unit tests then you are not doing TDD the right way. I bet most people don't know this.
1
@salvatoreshiggerino6810 I was also fired for tying to save a year of useless work long time ago. I was right - the project was total waste of time and it was stopped after almost a year but it had a purpose of getting money from customer - it was a fake project for an excuse for financial transaction. Since then I don't argue much against bad ideas from management.
1
Don't use London style because it is terrible. Integration testing is testing outside the process like access to database and filesystem and when you test more units of functionality in a single test one after another. Example of integration test is: login, creating a record, changing the record, removing the record and logout in a single test.
1
@llothar68 yes there is something fundamentally wrong with TDD or else more professional programmers would use it.
1
Great point! Also if there is a list of well defined requirements for legacy code without tests we can make good tests for that code too no matter how messy it is provided we can change the design so much that we can get the correct feedback from the system.
1
Yes Dave is lost in the theory that is far from reality.
1
OMG you were just like my leader 2 years ago and it was so annoying...
1
@architectelevator OMG are you the legendary Gregor Hohpe?
1
Yes Dave learn from Google, Amazon and Facebook! They are all writing classical unit tests with very few mocks and NOT the London style with lots of mocks everywhere.
1
Exactly. Unit test should exist to test functionality (the unit of functionality) and not to test some code - method or class just to get coverage.
1
@potaetoupotautoe7939 I am a senior developer and after applying for 100 jobs I got zero job interviews and I know some other senior developers with 20+ years of experience that have the same problem. Today it is extremely hard to get a job in IT for senior developers.
1
OMG I think your tests are bad too. It would be much better to use the real Transport and to check transport.lastMessageSent() in assert. That way you don't need mocking and verify - both make tests harder to read and understand and also your tests will be less coupled with implementation details like the calls to transport.
1
Great explanation of why we should do TDD.
1
Yes it is better to write your own mocks and to write as few of them as possible writing classic unit tests. London style is a terrible idea.
1
But there are many terrible unit tests in the world. All the London style tests should be deleted because they are worse than having no tests.
1
@rfphill yes those tests that mock everything outside the class under tests are the London style unit tests.
1
@aakarshan4644 By my experience projects in big companies are even worse than in small to mid companies and I worked on some of the biggest projects in Europe in teams counting more than 100 developers and some code was more than 30 years old.
1
Yes but you would be surprised to know how much of advice on writing good unit tests is just terribly wrong and also the best parts are completely missing from most books... For example how to determine which tests to delete when we cover the code with better/more useful unit tests...
1
@orlovskyconsulting no don't delete the code just the tests that duplicate testing that code. Keep the most useful tests that are a bit larger and delete small tests that are already covered by larger teste. It is better to have 10 large unit tests - that are stil unit tests and not integration tests than having 100 small unit tests.
1
@orlovskyconsulting crazy that youtube censored my answer to you. I hope you will get this answer: You should just delete the tests that are testing the code more than one time and don't delete the code. It is better to have 10 large unit tests than 100 small unit tests that test the same code.
1
The problem with TDD is that it is not applicable to every code - the code that uses a lot of random data where you should see the final result, graphic rendering...
1
I work as a contractor and I charge 20% less for the days that I work remotely because I don't spend 2 hours traveling to and from the job site.
1
Then you have a strange experience. Good developers are good in algorithms and refactoring to make code clean.
1
@plouf1969 OMG you should improve your knowledge of algorithms. You can find great lectures on youtube from top Universities for computer and information science. Good background in algorithms can drastically improve your ability to find good solutions for mathematically complex problems and you will not feel threatened by junior developers that know algorithms well. I agree that refactoring, designing good architecture, unit tests... are very important topics but everything starts with finding good algorithms for solving problems.
1
@plouf1969 I think asking about algorithms - (practical questions, not theory) at interview is great to see how good and fast is the candidate at formulating solutions to a problem. Of course the main focus should be on clean code and design skills.
1
Here is the deal. Give me a million € per month and I will pause my research in AI too. LOL!
1
Yes AI will soon replace mockists. LOL!
1
Yes Chicago style is good. London style on the other hand is terrible.
1
@evancombs5159 find explanations with google.
1
Only bad tests are bad. It is better not to have bad tests. Good tests will help you develop much faster with fewer bugs and will give you the control over complexity of the code so you can create much more complex logic without getting into huge trouble working on it - extending it, refactoring, redesigning and fixing bugs.
1
@nickpll But you should use integration tests for database and integration tests are usually much slower than unit tests so you usually don't run them together with unit tests.
1
@nickpll you don't use mocks in integration tests. Those tests are using database - usually empty test database that you fill with test data.
1
@dflor003 Refactor/redesign the system so you can test as much as possible with unit tests without mocks and the rest you test with integration tests so you never need to mock anything.
1
@dflor003 Don't mock calls to external API that execute inside the process. Only mock those that go outside the process like IO, database access, network... London style TDD is so silly focusing on the class while implementing top down. This is just breadth first implementation of functionality and it is inferior to depth first because in breath first you need silly mocks while you don't need mocks in depth first implementation of functionality. In depth first you are writing all classes that implement the functionality - satisfy unit test at once. Sometimes it is even better to create a "fat" class and then refactor it by extracting classes out of the fat class. You also shouldn't create a test class for every class. It is perfectly fine to test classes through "upper" client classes and their unit tests.
1
@danielwilkowski5899 Exactly! Mocking all dependencies to isolate class under test (London style unit tests) is a terrible idea that is killing the European software industry. Americans are writing mostly classical unit tests without mocking object interactions.
1
Here you have everything you need to know about requirements. The best way to develop is to start writing code despite a requirement is not perfectly defined. You implement it step by step and after each step owner should check it and give you feedback so you can continue with the next step.
1
@esra_erimez yes just start coding the initial basic idea.
1
@andersbodin1551 yes the shortage of jobs is still present.
1
Exactly! London style was invented by programmers who have no clue about unit tests.
1
Are you doing TDD with classical or London style unit tests? You should know London style is terrible.
1
@7th_CAV_Trooper yes but you should always be able to get rid of bad hires because no matter how many interviews you have you can't find out whether he is really such a nice, honest and hardworking person like he seems on interviews.
1
@ModernSoftwareEngineeringYT I wonder what do you propose for teams working on large code base that don't do TDD and have less than 10% coverage. Should they write more unit tests or it is better to continue without unit tests?
1
Yes London style tests are too granular and this can lead into huge troubles when changing/refactoring the implementation details so this is why classic tests are far better than London style tests.
1
@HakanaiVR but we sometimes want to fail at the edge conditions. For example conditions that should never occur in the production software. We want to get the exception so to know there is something seriously wrong. We don't want to hide the failure.
1
@HakanaiVR This is not the edge condition that you described. You described the change in functionality. When change happens and old unit tests that covered the old functionality fail we should delete them. It is naive to think anyone can write the application correctly from the start. I guess you don't have much of experience writing code.
1
Writing mocks is usually bad except when mocking resources that are outside the process because there is no other way to create a unit tests for code that accesses those resources. I guess they removed unit tests that were full of mocks - the terrible unit tests. Unit test can have more than one assert but it should never have multiple steps because in that case it is not a unit test but contains more tests inside one test.
1
@jameswrightson744 just google the difference between London and classical style unit tests.
1
My advice to junior developers for a job interview is to be confident if interviewer is confident and to show enthusiasm for the job they are applying. I think this is more important than the current knowledge they have.
1
You should study London and classical style unit tests in depth and then you should expose London style as a terrible idea that is killing many projects.
1
I agree about OOP and FP but this doesn't mean everything is like that. Classical style unit tests are much much better than London style unit tests.
1
@witchedwiz I didn't say you should never use mock. You should mock all calls to external systems. What you shouldn't do is to mock all calls outside the "class under test" because such unit tests are terrible.
1
@witchedwiz it is better to go top down without mocks except when mocking calls outside the system. You don't need to write unit tests for a class that is already covered by unit tests of its client classes.
1
Yes they sadly skip the most important lectures for future developers.
1
@harryd5571 the problem with incompetent developers is that they are afraid to hire someone that is much better than they are. It is important to recognize such a person - buyer and make him feel good by demonstrating that they are better at that job then you are. I know it sounds crazy but life overall is quite crazy. Don't you think so?
1
@harryd5571 yea I don't like long term commitments.
1
You should use agile Kanban.
1
You don't use TDD to develop UI because you need visual inspection and the best tool for that are your eyes.
1
Just use as few mocks and other test doubles as possible and don't use any mocking libraries and don't write London style unit tests because they are terrible idea.
1
Great point! Dave should ask Martin Fowler why he is not using TDD everywhere.
1
@salvatoreshiggerino6810 I've spent 20+ years in the business and never saw it being used except by me when it makes sense to use it.
1
@bodo_Te it is TDD not TTD. LOL!
1
@PawelRokicki-z2x I am a java developer and I am looking for a job in Germany and Austria and I have a friend who is also having a hard time finding a job there as java developer and he is even more experienced than me.
1
@vitalyl1327 yes and in many cases low quality candidates have better chances of getting the job than high quality because they are very cheap. I believe that over time market will improve for candidates.
1
@vitalyl1327 I am the competent developer with 20 years of experience in java, C#, C++. I worked on some of the biggest projects in the world. I know and have experience with design patterns, SOLID principles, refactoring, creating good unit tests, TDD, domain driven design... I can deliver solutions fast with clean code, great design and protected by unit tests. So please tell me where can I get a job?
1
Yes unit tests are great but you should know how to write them and you should also know that London style unit tests are terrible idea.
1
@marna_li top down from interface is a good way to start. Just don't let the top down approach spoil the design of your project. You should remove dependencies from lower level business logic as much as possible and put them to higher level simple controlling logic like GUI...
1
Focusing on code under test is bad when writing unit tests. We should always focus on functionality that we want to test instead.
1
60 thousand unit tests on a smaller project than Twitter? This is way too many! You should delete probably 90% of them. I guess you have so many because you are mocking out everything that is not in the class under test. London style tests are terrible so you have 60 thousand terrible tests that you should replace by maybe 6000 classical tests similar to Amazon and Google unit tests.
1
People don't know how to do the TDD properly even those that have many experience doing it. The key to properly do the TDD is in DELETING many unit tests that are fully covered by larger and more useful unit tests like Kent Beck proposed in his famous book. Unless you are deleting many smaller unit tests you are not doing TDD properly and so you end up with way too many unit tests that are too small and rather useless.
1
Hi I would like to hear tips about unit testing classes that communicate with DB and if there are any good tools to simulate the communication through ORM or plain sql.
1
@ModernSoftwareEngineeringYT thank you. I already saw that great video. I wish you could go a bit deeper on the subject because it is hard to find material on how to make unit tests near the edges of a system.
1
I think we spent most of our time as professional software developers analyzing existing code. In medium and large projects we spent 80%+ of time reading and trying to understand existing code. We spent less than 20% typing and testing the our latest changes to the code. The key to speed up software development is to write clean code so we can understand it faster and to have a good suit of good unit tests that protect the existing functionality so we don't need to study the existing code so hard because we trust unit tests to prevent us from breaking something.
1
Unit test should be a black box test that knows nothing about the implementation of functionality it is testing. There is the London unit testing style that is coupling unit tests to the classes they test and that style is just terrible. Use the classical unit test style.
1
@robocodeboy I must warn you that in memory dbs can give you a lot of trouble because they are not compatible with the persistent dbs. You should separate business logic from db access logic and test the interaction with an empty persistent db in slower integration tests. You test business logic with fast unit tests.
1
@ModernSoftwareEngineeringYT OMG your tests are bad too. It would be much better to use the real Transport and to check transport.lastMessageSent() in assert. That way you don't need mocking and verify - both make tests harder to read and understand and also your tests will be less coupled with implementation details like the calls to transport.
1
Mocking frameworks are terrible! Stay away from them. Use integration tests for testing IO, DB...
1
@1879heikkisorsa you can use TDD without mocking anything except calls outside the system - like calls to database or filesystem... You can do it bottom up layer by layer or top down. With top down just temporary return from lower layer until you implement the lower layer and then you refactor temporary solution to use the lower layer and tests should all pass... I hope you understand what I mean.
1
@1879heikkisorsa Yes in this case you can mock the repo by extending it with your test repo. Just don't use mocking frameworks because they are terrible.
1
STOP WRITING LONDON STYLE UNIT TESTS because they are terrible for projects!
1
@thatoneuser8600 I am trying to save Europe from London style unit test. We are losing billions because of bad tests.
1
@PavelHenkin London style unit tests are actually class tests. Every call outside the class under tests is mocked.
1
@ModernSoftwareEngineeringYT I watched and commented on the video 4 months ago. You should make another video condemning London style. If you really think why we need unit tests and what is a good unit test then you will find out how bad are London style unit tests.
1
@PavelHenkin You got it! It is interesting how many smart developers just don't get it. It seems like Dave Farley is one of them.
1
I also think his tests are terrible - too coupled with how system works and hard to read because of mocks.
1
Mockists are writting terrible unit tests because they are hard to read and understand and are coupled with implementation. Use integration tests whenever your program accesses resources outside the current process like DB, filesystem, web... You can write integration test first and then unit test from that integration by mocking the access to outside resources.
1
@plartoo yes huge systems are complex but when you have good unit tests then you can extend even the most complex systems rather easily and fast.
1
@josephp.3341 this doesn't make sense. It is easy to get a job when there is a labor shortage. Getting a job is very hard because there is a large labor surplus competing for available jobs.
1
OMG once you get used to it Pair Programming is better than sex with a hot woman!
1
@deanschulze3129 Great question. I think TDD has some fundamental problems that deter most professional programmers from using it. I think TDD is a bit like socialism - good in theory and for some people but not so good for most. The problem I see is that promotors of TDD only tell us good things about TDD and never bad like it is useless when creating GUI in code, using random data... Sometimes it is just too silly to write a test first. I think the worst thing about TDD is jumping from writing test to production code and back to test - the mental process that most programmers just don't like doing it. I must say that I like TDD whenever I write logically complex code - business logic.
1
@JBoy340a when they really need people they are glad to get someone no matter his age, gender, race, hair style, size...
1
Unfortunately in reality software development is more about office politics than coding.
1
@AndrewEddie yes Dave is sometimes more idealist than realist.
1
You don't need tests for tests because tests should contain only trivial logic so no loops or conditions or complex calculations. Tests for trivial logic in production code are usually useless so you shouldn't write them.
1