Upgrading my tech skills.. Once again I feel my personal my personal dev environment and told are much more up-to-date than what I use at work.... Though the book Kim reading is on TDD and was written 3 years ago.

Maybe I should read another on in cloud services and ML... but don't have any motivation for these topics.

I need TDD for work because now we're emphasizing unit test coverage...

I usually only use manual functional tests to verify the final outputs as either the testing framework is broken (JS) or I don't have time to relearn the frameworks for the particular language...

Anyway got off topic... So questions after:

1. Do you ever feel your technologically always more ahead than what you do at work and essentially you bring skills to the job but you don't learn much out of it?

2. How do you test? I actually got into a bit of a argument/discussion with my colleagues about how to implement unit tests. Apparently there are 2 ways to test? Black box vs WhiteBox. She said she tests only Public methods using mock inputs, dependencies. She read online and seems there is an opinion that should only test public functions and if you can't then your app is designed incorrectly, not separated enough.

For me I test the private functions individually (WhiteBox/Java reflection) because the public one is like generateReport and as a whole is like a Pachinko machine, too many unique paths that would need a test case for.

So thoughts? Yes sorry for turning it into a remake I guess...

Great questions 👍👌
1. I usually bring skills to the job, but I don’t know if I am under skilled because there are so many technologies and frameworks right now and I am working and making 2 projects at a time
2. I make white box tests - end to end for protocol changes between systems, unit testing of REST api by comparing response with a server.
Black box testing is for testers and they do it manually 😂

From my personal observations:
I started working with machine learning recently for my side project to generate sound and it’s most worth to see from anything new that happened recently in the IT industry.
I see huge progress from what I’ve seen 10 years ago and what I see now in this topic.

@vane Actually I just reread my post... So many typos... Seems lately Gboard is getting dumber... Some are like wtf the letters aren't even close and there's no context to use this word in the sentence. I remember it said it predicts partly by using the words previously typed?

Actually if you call the APIs externally that would be BlackBox though? Since it would be testing a function that calls other functions depending on the different parameters passed in? If one fails you can't really tell which actual function is the issue. Would need to debug with that specific case to find out?

@billgates I log stack trace of each call to the file so I can fix it easy.
White box and black box is more about methodology then actual testing, it’s like agile but described like schrodinger cat.
It depends how well you know the product, I am one person backend developer team doing product so I can decide what to do and what not to do and when.

From cloud related things - docker if you don’t know it you should, cause it would automate your job and speed up things.

https://katacoda.com - you can learn docker, cloud and some machine learning basics

Don't private methods exist solely to fulfill the contract of public methods? They are just one example of whatever internal magic exists to implement your thingy.

If you test the public methods then you'll verify all the internals, private methods included. If you have full coverage for some set of public methods but the private methods are not covered then that just means that you've got some internal code laying around that you can delete because it's obviously not doing anything useful (at least today. So YAGNI).

My two cents 😘

@vane Yea I used to be like that in my old team, 1 person. But not in current one. The issue though is automated test coverage. I have like a manual functional/regression test that diffs the final output. It could be automated but it wouldn't serve much of a purpose other than Different, Same. For the actual details, you would have to read the diff report and reproduce with whatever input was used and debug the whole app.

WhiteBox I'm sorta thinking is, if you validate all methods individually work for all their use cases , you can say since all of them work correctly then the app is correct even if there is only one public entry point. And if the final result is wrong, the issue isn't in those tested components, it's in the function that glues them all together. So just need to look at that one.

@ihatecomputers But say there only one public methods in the class but it does a lot of work like a data aggregation so it's filtering, summing, etc. You can't rely test all cases without creating like 50 different test cases so all possible combination of paths are traversed?

@billgates I automate everything in my job also testing / deployment/ development etc my CI now looks like this :
I commit something,
jenkins update stage / test environment
run tests ( I got that in near future )

You should not do this manually and focus on writing tests.
Any tests are better then none.
Look what data changes the most during execution and start from critical parts if you spot some.
You typically got some database / external systems / public api - I described those in order of importance.
When you fuck up db - you’re done
When you fuck up external systems it might be fixed
Public api depends how public it is and who use it

@ihatecomputers actually I just thought if a good example maybe? Collections.sort()

Not exactly sure how it works but I I think it determines the actual sorting also to use internally? What if one of the algo it uses is buggy?

The only way with test public only would be to seperate the implementation into a different class that is only public to the Testing app? Or figure out the exact inputs that lead to triggering the algo and reproduces the bug.

I guess sorta of like needs 1 more Step. Like ways error on line 30. Well have to figure out how to get to line 30 and also trigger the error.

@billgates
Oh, I totally get that Pachinko machine thing. Like, you got one public method whick is the entry point and then you've got a lot of branching and stuff happening based on input? Yeah, that had tripped me up loads of times. I can see the urge to test privates in that case. But that won't guarantee that your feature is working because the entry point is coordinating calls and you haven't tested that part at all. So, if we're being realistic, all that testing hasn't done much to ensure that your program is doing what it's supposed to.

What has worked for me in the past is seeing your public entry point thing as some kind of coordinator. You only need test that it is calling the correct functions in the correct order with the correct parameters, depending on which scenario you're verifying. So you'll have to verify that for every case. This means that you can take all those internals and pull them out into their own modules (classes, functions, whatever) which will only be responsible for whatever they are doing. Now they have a public interface which is used by your coordinator. You just pass those your coordinator, they are now your coordinator's dependencies.

Ohhhh, this means you can test them because they have public methods now. So you write tests to verify these dependencies. Alright. This means that your dependencies (previously private methods) are passed to your coordinator thing. You give those dependencies an interface so you can exchange them for mocks when testing your coordinator.

You'll end up with:
One coordinator thing which calls the correct dependencies in the correct order with the correct parameters.
Some other things which are proven to do the right thing when passed certain parameters.

So, everything is tested. You even get the satisfaction of testing those previously private things, because they are now obliged to implement their own public interfaces.

I hope this makes sense.

@vane yes, I mean dev team that's what I did too because I am God. Same when I'm at home, no one can argue with me about how to do things.

Now I have to deal with people, I need to figure out what is more right and adapt to them or convince that my way is more correct and they should change. And well let's just say I've been doing that since day 1... Don't help much until some bigger boss comes down and says your team need to do achieve automated test coverage of 80%. And so we now debating this question.

Yes there are many ways to achieve 80% like you said but which is the most logical, efficient, and useful for the long term.

TDD I think it's basically test all functions, you will know exactly what you broke immediately when you break it.

Functional is more like you make all the changes needed for the app to run and then at the end you see it doesn't work correctly. Need to now figure out which part(s) broke it.

@ihatecomputers it sort of does but that would lead to a explosion of classes that have 1 or 2 functions that only have 1 caller. They can't be reused for other purposes. Actually do you know any public open source projects that do this. I tried Googling TDD examples or something but haven't found any complex enough to match the code I work with at work.

@billgates

I don't really understand the sort thing but if you're using Collections.sort you have to trust that it is implemented correctly. Just like that you to trust that 1 + 1 gives correct output. It's out of your control.

What you CAN do is testing your function in terms of scenarios. You have to forget that you know how it is implemented. There is no line 30. You only have a public method and a couple of SCENARIOS that you need it to handle correctly. Each scenario is formulated using different input. "Don't send an email if the account is inactive" will become a test case where you set up data to validate that specific case. You're not testing lines codes inside the public method, you're testing to see if this specific input = expected output.

This will make you feel a bit uneasy, because you want to test everything inside. But if you look at it the other way: I want to make sure that this method can handle all possible combinations of input data. Well, just look at code coverage for that method. If it's less than 100% then it means that there are code paths (or, lines of code) that aren't being touched by a test. Just add more tests until you've covered it all.

@ihatecomputers Actually I remember now one issue I've had with too many Interfaces , is I ending up with a function that takes N Interfaces so I remember before (and maybe because this was back when all the dependencies were declared in Spring XML.), I needed to backtrace to figure out how to initialize an instance of the class before I could even try to reproduce the issue. And of course Spring has like Context stacking so need to go through all the XMLs. Maybe the design is wrong but what happens is the only way to even test the code is to remote debug it so all the Spring created objects are correctly initialized.

@billgates
Alright. Yeah, it's easy in theory but I dunno how your code looks like so maybe this isn't very helpful. Sorry, dunno about any good examples.

@billgates I am big fan of bdd tests lately

@ihatecomputers no problem, thanks though. Helps getting different views instead of just reading theory.

Maybe it's the legacy code. Need to do it from the start or else you have a huge mess left by other devs to clean up first...

@vane BDD only works if the business can actually define the requirements?

The one I'm doing right now, the requirements is: make the report match what we currently get in the old system. The report is huge and very complex, lots of data sources that needed to be migrated.

Can't unit test that. I had to create an app that takes both versions and diff them.

@billgates well there is a language called gherkin to describe functionality if you can capture your functionality in that language you can use it.
BDD is often described as end to end method of testing your application.

I use it to integrate frontend and backend.

Probably you should use it to define your properties in report and describe how those properties appeared there then you will have more knowledge about the functionality of the previous application(s)

In agile environment business requirements are changing 🙂
You can also look at agile test pyramid, it will give you some visuals.

If you plan to rewrite software from scratch with more then one person you can start with defining interfaces -> write unit tests that have given output you agreed -> write actual code

I have never have ability to work that way but it’s cool, and you will have full code coverage.

@Nanos it's for automate testing to make sure nothing is broken
https://softwaretestingclass.com/di...

@billgates Maybe there are no open source projects that enforce TDD / high test coverage because it increases the entrypoint for contributions ...
But it's still best practise and if you can use it, do it!
Also, seperate classes that change often from non-changing classes.

@Ederbit I sorta of want to see a decent sized production project to see how the code is actually structured. I can't quite think about how you can do away with needing to test private functions like if you implement a class with custom algorithms but there's one public method that uses all of them... You would still need to test those to be confident they individually are correct, not broken by some change right?

@billgates Chance is, if you have a class containing multiple algorithms, it does too much. Make that class just a "coordinator" class (like @ihatecomputers suggested) using multiple other classes, each implementing their algorithm. Then you can test those algorithms individually.

On Stackoverflow I found FitNesse and the spring framework recommended as a well written open source project. Take a look at these, but remember that every project is structured a bit differently.